> 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 ...)
-- mingo
-
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/