Re: Can context switches be faster?

David Lang
2006-10-13T23:48:37Z

On Sat, 14 Oct 2006, Andreas Mohr wrote:

> OK, so since we've now amply worked out in this thread that TLB/cache flushing
> is a real problem for context switching management, would it be possible to
> smartly reorder processes on the runqueue (probably works best with many active
> processes with the same/similar priority on the runqueue!) to minimize
> TLB flushing needs due to less mm context differences of adjacently scheduled
> processes?
> (i.e. don't immediately switch from user process 1 to user process 2 and
> back to 1 again, but always try to sort some kernel threads in between
> to avoid excessive TLB flushing)

since kernel threads don't cause flushing it shouldn't matter where they appear
in the scheduleing.

other then kernel threads, only threaded programs share the mm context (in
normal situations), and it would be a fair bit of work to sort the list of
potential things to be scheduled to group these togeather (not to mention the
potential fairness issues that would arise from this).

I suspect that the overhead of doing this sorting (and looking up the mm context
to do the sorting) would overwelm the relativly small number of TLB flushes that
would be saved.

I could see this being a potential advantage for servers with massive numbers of
threads for one program, but someone would have to look at how much overhead the
sorting would be (not to mention the fact that the kernel devs tend to frown on
special case optimizations that have a noticable impact on the general case)

David Lang