Messages in this thread | | | Date | Wed, 29 Mar 2000 22:07:20 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] preemptive kernel, preemptive-2.3.52-A7 |
| |
On Wed, 29 Mar 2000 yodaiken@fsmlabs.com wrote:
> Scene1: without need_resched checks > Scene2: with need_resched
we prefer Scene2 over Scene1 in 99.9% of the time. After all, the guy sitting in front of the machine and generating interactive events has payed for the hardware so we should preempt ASAP if needed :-)
if a process is rescheduling frequently (so that it can make the imaginery disaster scenario happen in Scene2) should not really happen, because it's not an interactive task anymore. A newly woken up thread with the same priority does not preempt the currently running thread, plus the currently running thread gets a +1 goodness, to model the cache trashing issue you raised. Check out preemption_goodness() in sched.c.
_If_ a thread is so interactive that it's sleeping most of the time and is collecting priority through recalculation, then we should schedule to it as fast as possible. The frequency of human interactive events is rather low. (barring casual mouse movement, which is mostly lightweight)
Ingo
- 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/
| |