lkml.org 
[lkml]   [2005]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: cpu_exclusive sched domains fix broke ppc64
Paul Mackerras wrote:
> I'm not sure what the best way to fix this is

Thank-you for reporting this. Likely the best way to fix this for now,
since we are late in a release (Linus will probably want to wack me
upside the head for breaking his build ;) is to leave the
node_to_cpumask and for_each_cpu_mask exactly as they are, and have the
code that my cpu_exclusive sched domain patch added make a local copy
of the cpumask.

I just sent off a patch to do this - quite untested so far.

I am trying now to get fire up crosstools to verify the build.
But if you can get it to build anytime soon, let me know. My
crosstools are rusty -- it might take me a bit to resuscitate them.

I also am not sure what is the best way to fix this detail with
node_to_cpumask and for_each_cpu_mask in the long term. The choices I
see are:

1) Leave it be - which makes it easy trip the build bug I hit,
due to the different styles of node_to_cpumask, inline or
macro, on different archs.

2) Make node_to_cpumask a macro on all archs, though that
makes it even easier than it is now to write code that
appears to modify a local variable, but actually modifies
some global array of the per-node cpumasks, which could
lead to some juicy runtime bugs.

3) Make node_to_cpumask an inline on all archs, though that might
force a local stack copy of a cpumask in places that might
be performance critical on arch's with big cpumasks.

4) Perhaps some more subtle combination of macros/inlines
can be all things to all arch's.

I'm not going to unravel the above tonight.

> it seems unfortunate that for_each_cpu_mask
> requires the mask to be an lvalue, but that isn't documented anywhere
> that I can see.

Are you saying that it's unfortunate that for_each_cpu_mask requires
an lvalue, or that it's unfortunate that this isn't documented?

Or both ;).

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-24 14:07    [W:0.023 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site