Messages in this thread | | | Date | Fri, 26 Feb 1999 10:44:00 +1100 | From | Richard Gooch <> | Subject | Re: 2.2.2: 2 thumbs up from lm |
| |
Ingo Molnar writes: > > On Thu, 25 Feb 1999, Richard Gooch wrote: > > > I wasn't thinking in terms of long run queues, actually. Well, not > > hugely long like dozens of tasks. Even a with a few tasks, thread > > switching is measurably worse due to aliasing. [...] > > the PII L1 cache is 16K and is 4-ways associative. This means the first > time we have a _chance_ to get cachelines kicked out is with 5 running > threads. There is no way you can place 4 task_structs to be misaligned. > And chances are almost zero to get a collision in the 512K+ L2 cache.
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/
| |