[lkml]   [2000]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: needed scheduler improvements (was: Re: SCO: "thread creati

On 23-Aug-2000 Rik van Riel wrote:
> There's also another thing which I'd like our scheduler
> to do right. Suppose we have 2 processes running in the
> background, calculating stuff (they'll both become low
> priority, which is good).
> Now one of the processes is halfway it's timeslice and
> gets interrupted by something. After that short interruption
> Linux continues with the _other_ cpu intensive thread,
> blowing the cache and making the system slower than it should
> be.

Some time ago I did some work to allow CPUs to "hold" a preempted process so
they can switch back to it without looking at the run queue when whatever
preempted them goes away. There were certain restrictions (process must be
non-interactive SCHED_OTHER, no nested preemptions) and the timer interrupt
would release the process if it had failed to reacquire the CPU within a
tick. The trickiest part is determining whether a process should be held.

Other enhancements to consider:

When reschedule_idle preempts a CPU it is usually unecessary for that CPU to
scan the run queue. Often it can just switch to the preempting process in
constant time. Particularly so if the CPU was idling. It may even be
possible to avoid taking the runq lock in this case.

Taking running processes off the run queue. With one CPU it makes sense to
leave executing processes on the runq, but on a busy 16p box this guarantees
a run queue length of at least 15. And touching a task_struct tends to cause
L1 cache misses.

> A third issue would be NUMA (and maybe some SMP) scalability.
> We may want to have 'local' (per node, or per cpu) run queues
> with a less opportunistic thread migration between cpus.

For one thing, on NUMAs we need to distinguish between stealing a process
from another CPU on the same node and stealing from a remote CPU. The latter
is much more expensive.

Dimitris Michailidis
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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