Yes, but I've been doing most of my benchmarks on a PPro and plain
P5's. And some of the target machines they have in mind are lowly
386's or 486's. 386 embedded systems are expensive enough, going to
486 or beyond adds a lot to the cost.
So they want to do the most with the least hardware cost. Some of
these systems will be sold (or the software is provided) to smaller
institutions which have smaller budgets.
> > I don't see your point about penalising the "common, few threads"
> > case, though. To me it looks like it improves performance
> > *always*. Where is the performance hit?
>
> the (obvious i think) cost is in the indirection of the 'outsourced'
> runqueue (well, scheduling) part of task_struct. Think of it this
> way: you are basically doing the CPU's job, you are slightly fixing
> up the cache architecture via introducing one more indirection (and
> quite some added complexity).
I agree. I did say I wanted to try this and I also said I didn't know
for sure whether it will make a difference. I'll have to try to see.
I'm also going to compare how this works with a kernel which doesn't
change the scheduler but does have page colouring.
I don't claim to have all the answers. I have a number of ideas that
I'd like to test. The main claim I make is that I don't think it's
obvious which approach will be the best. At least I'm willing to code
something and test it. That seems more constructive than persistently
poo-pooing ideas (I'm not saying you've done that, I'm just tired of
the flack I've received on these issues).
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/