[PATCH] 2.3.41 scheduler change

[Dimitris Michailidis]

Rik van Riel <riel en nl.linux.org> writes:

> When you press a key in vi and the currently running runnable
> process gets descheduled, it will have a lower priority than
> the other process (because it's used part of its timeslice)
> and immediately after vi the _other_ running process gets
> scheduled. This could result in unneeded cache thrashing.
> 
> My patch calculates a slower-moving priority so that short-term
> use of CPU (within one timeslice) doesn't influence priority.
> This means that the _same_ running process will be rescheduled
> after vi goes back to sleep, this should reduce cache thrashing
> and increase efficiency.

This looks like an attempt to implement temporal affinity.  Here's an
alternative idea for this (I haven't implemented it and I don't have any
performance experience with it, it's just an idea):

When you switch from process A to process B, if process B has a very short
avg_slice retain ownership of A by leaving its has_cpu=1 and make a note of
it in some local state (probably schedule_data).  This keeps other CPUs from
taking A away.  When process B gives up the CPU (and we expect this will
happen in a very short amount of time) we can switch back to A in O(1) time.
Most of this can be done in __schedule_tail().  In fact, reschedule_idle()
already has a test for avg_slice and pretty much my proposal would have a
similar test in __schedule_tail() and depending on the result we would either 
retain ownership of the descheduled process or go into reschedule_idle().
There are some other pitfalls to deal with, such as making sure we don't try
to hold more than one process at a time, but they appear trivial.

Comments?

-- 
Dimitris Michailidis                    dimitris en engr.sgi.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/