Messages in this thread | | | Date | Mon, 24 Aug 2009 20:21:54 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 15/15] x86: Fix cpu_coregroup_mask to return correct cpumask on multi-node processors |
| |
* Peter Zijlstra <peterz@infradead.org> 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
| |