Messages in this thread | | | Date | Wed, 23 Aug 2000 15:41:31 -0700 (PDT) | From | Dimitris Michailidis <> | Subject | RE: 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 dimitris@engr.sgi.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |