Messages in this thread | | | Subject | Re: [PATCH] 2.3.41 scheduler change | From | Dimitris Michailidis <> | Date | 29 Jan 2000 14:27:17 -0800 |
| |
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/
| |