> I have been working on scheduler scalability. Specifically,
> the concern is running Linux on bigger machines (higher CPU
> count, SMP only for now).
very simple reason: #ifdef's in code.
Why do you have things like
.. use nr_running() ..
.. use nr_running ..
when it just shows that you did NOT properly abstract your thinking to
realize that the non-SMP case should be the same as the SMP case with 1
CPU (+ optimization).
I find code like the above physically disgusting.
What's wrong with using
unconditionally, and make sure that it degrades gracefully to just the
What's wrong whit just using
and having the UP case realize that the "runqueue()" macro is a fixed
Same thing applies to that runqueue_lock stuff. That is some of the
ugliest code I've seen in a long time. Please use inline functions, sane
defines that work both ways, and take advantage of the fact that gcc will
optimize constant loops and numbers (it's ok to reference arrays in UP
with "array[smp_processor_id()]", and it's ok to have loops that look like
"for (i = 0; i < NR_CPUS; i++)" that will do the right thing on UP _and_
And make your #ifdef's be _outside_ the code.
I hate code that has #ifdef's. It's a magjor design mistake, and shows
that the person who coded it didn't think of it as _one_ problem, but as
So please spend some time cleaning it up, I can't look at it like this.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/