Re: [PATCH 15/15] x86: Fix cpu_coregroup_mask to return correctcpumask on multi-node processors

[Ingo Molnar]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Thu, 2009-08-20 at 15:46 +0200, Andreas Herrmann wrote:
> > The correct mask that describes core-siblings of an processor
> > is topology_core_cpumask. See topology adapation patches, especially
> > http://marc.info/?l=linux-kernel&m=124964999608179
> 
> argh, violence, murder kill.. this is the worst possible hack and 
> you're extending it :/

I think most of the trouble here comes from having inconsistent 
names, a rather static structure for sched-domains setup and then we 
are confusing things back and forth.

Right now we have thread/sibling, core, CPU/socket and node, with 
many data structures around these hardcoded. Certain scheduler 
features only operate on the hardcoded fields.

Now Magny-Cours adds a socket internal node construct to the whole 
thing, names it randomly and basically breaks the semi-static 
representation.

We cannot just flip around our static names and hope it goes well 
and everything just drops into place. Everything just falls apart 
really instead.

Instead we should have an arch-defined tree and a CPU architecture 
dependent ASCII name associated with each level - but not hardcoded 
into the scheduler.

Plus we should have independent scheduler domains feature flags that 
can be turned on/off in various levels of that tree, depending on 
the cache and interconnect properties of the hardware - without 
having to worry about what the ASCII name says. Those features 
should be capable to work not just on the lowest level of the tree, 
but on higher levels too, regardless whether that level is called a 
'core', a 'socket' or an 'internal node' on the ASCII level really.

This is why i insisted on handling the Magny-Cours topology 
discovery and enumeration patches together with the scheduler 
patches. It can easily become a mess if extended.

	Ingo
--
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/