Messages in this thread | | | Date | Thu, 25 Feb 1999 22:07:15 +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: > > > My basic idea is to pack all the per-task information necessary for > > the scheduler to walk the run queue (and no more) into a new > > structure. Call it struct task_sched. This will be the framework for > > the run queue. All the other cruft is left in struct task and a > > forwards pointer (and possibly a backwards pointer as well) takes you > > from the struct task_sched to the struct task. > > I see your point. What about architectures with sane L1/L2 caches? > Also, even if we assume that most architectures would benefit from > this from the pure cache alignment point of view, this method > penalizes the 'common, few threads' case, and optimizes the 'many > threads' case. Even heavily loaded servers get only very rarely into > double digits runqueue sizes ... The Linux scheduler is _not_ > optimized for long runqueues. (That having said, we are not bad with > long runqueues either, but if you have non-benchmark long runqueues, > you'll probably have bigger problems than scheduler overhead ...)
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. This is of course a side effect of having such incredibly fast thread switching times, so you start to notice a few cache misses here and there :-)
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?
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/
| |