Re: 143e1e28 sched: Rework sched_domain topology definition

From: Mike Galbraith
Date: Sun Jul 20 2014 - 03:06:10 EST


On Sun, 2014-07-20 at 08:52 +0200, Peter Zijlstra wrote:
> On Sun, Jul 20, 2014 at 08:43:36AM +0200, Mike Galbraith wrote:
> > Hi,
> >
> > +/*
> > + * Topology list, bottom-up.
> > + */
> > +static struct sched_domain_topology_level default_topology[] = {
> > +#ifdef CONFIG_SCHED_SMT
> > + { cpu_smt_mask, cpu_smt_flags, SD_INIT_NAME(SMT) },
> > +#endif
> > +#ifdef CONFIG_SCHED_MC
> > + { cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(MC) },
> > +#endif
> > +#ifdef CONFIG_SCHED_BOOK
> > + { cpu_book_mask, SD_INIT_NAME(BOOK) },
> > +#endif
> > + { cpu_cpu_mask, SD_INIT_NAME(DIE) },
> > + { NULL, },
> > +};
> >
> > Why did this commit rename the CPU domain to DIE?
>
> Because they're both wrong, but we found that DIE was less wrong than
> CPU.

Ok, doesn't matter anyway, just looks peculiar.

> Seeing how CPU typically means 1 logical, well, CPU, in the scheduler,
> and not the package you stick on your board.
>
> We chose DIE over PACKAGE due to 1) its shorter name and 2) things like
> interlagos which have multiple DIEs in one PACKAGE etc..

It's actually a good name for some NUMA topologies. You don't ever want
to see a CPU domain, that sucks cycles, so calling it DIE is fine :)

> Also, the only person who would ever care is the one who (with
> SCHED_DEBUG) enabled looks at the topology setup, which is maybe all of
> us 5.

Maybe a few more, but yeah, not many would care what you called it.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/