Rik van Riel <riel@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@engr.sgi.com- 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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:24 EST