lkml.org 
[lkml]   [1999]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:1.391 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site