Re: 143e1e28 sched: Rework sched_domain topology definition

[Mike Galbraith <umgwanakikbuti@gmail.com>]

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