Re: lowish-latency patch for 2.4.0-test9

From: Andrew Morton (
Date: Tue Oct 10 2000 - 08:20:16 EST

Andi Kleen wrote:
> On Fri, Oct 06, 2000 at 10:00:36PM +1100, Andrew Morton wrote:
> > The little-low-latency patch for test9 is at
> >
> >
> >
> > Notes:
> >
> > - It now passes Benno's tests with 50% headroom (thanks to
> > Ingo's scheduler race fix).
> What was that race exactly ?

Not completely sure. I _think_ the problem was that when the kernel was
switching from your SCHED_FIFO process to some other process, and an
interrupt occurred between the reenabling of interrupts and the
switch_to() in schedule(), and that interrupt tried to wake the
SCHED_FIFO process, it wasn't noticed until the next timeslice. That
was as far as I got when the problem magically disappeared. Due to
this hunk:

        switch_to(prev, next, prev);

+ if (current->need_resched)
+ goto tq_scheduler_back;


> There is a scheduler race which may also hurt (and is harder to fix):
> when the timer interrupt hits in syscall exit after the need_resched check
> was done then you may lose a time slice. The window can be quite long
> when signals are handled (after do_signal returned there is no reschedule
> check). Without signals it is only a few instructions window.
> I have not checked if it really is a problem in practice though. With
> lots of signals it may be a problem.

Is it not a matter of:

a): checking need_resched after the call to do_signal() and

b): disabling local interrupts prior to the final need_resched
    check to make this test atomic wrt interrupts. RESTORE_ALL
    will do the right thing and an intervening smp_send_reschedule()
    will be blocked until the return to user space.

Seems too simple...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:15 EST