Giuliano Pochini wrote:
> 0 disable interrupts
> ....
> ....
> 1 set reschedule flag
> 2 enable interrupts
> 3 iret
>
> If an interrupt occurs betweet 2 and 3 the flag value gets lost.
>
> What means interrups are disabled ? Incoming ints are simply ignored (I
> really don't thin this is the case) or are they queued ? Because in that
> case we get an int immediately after the enable-int call, and the window
> where we can get an int is 0-3, and not 2-3. Way larger.
Actually there's "2.5 check current->need_resched". You only lose if an
interrupt happens between 2.5 and 3, which is about 7 instructions
long.
For system calls, interrupts are not disabled at all.
I prepared a patch which fixes this in the nested interrupt -- when
returning to kernel space, if you're returning to those 7 instructions,
trigger a recheck of current->need_resched. It's quite efficient
because it doesn't impact all the normal code paths.
Ingo produced a nice and very small patch which simply disables
interrupts between 2.5 and the iret. That has overhead for syscall, but
let us see that the problem does occur and is fixed by doing this.
My patch can now be found in Ingo's grand low-latency patch.
have a nice day,
-- Jamie
-
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 : Fri Mar 31 2000 - 21:00:14 EST