[lkml]   [2009]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 15/15] x86: Fix cpu_coregroup_mask to return correct cpumask on multi-node processors

* Peter Zijlstra <> 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
> >
> 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

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.


 \ /
  Last update: 2009-08-24 20:25    [W:0.115 / U:6.280 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site