Jamie Lokier wrote:
>
> Jun Sun wrote:
> > First of all, I think this is must-fix bug. (Any arguments here?)
>
> There are a few other scenarious where need_resched is missed, including
> the last few instructions after ret_from_syscall. And it really does
> happen there. I think it's a must-fix too, but the fact that neither my
> nor Ingo's patch made it in suggests Linus thinks otherwise.
>
> enjoy,
> -- Jamie
Actually the scenario I described is more serious than the one
right before ret_from_syscall.
If an interrupt happens right before ret_from_syscall, the need_resched
is set in the CURRENT process. Yes the current process will go back
to user mode and continue its execution. But 10 ms later, the timer
interrupt will happen, and an examination of the need_resched flag would
convice kernel to do a rescheduling. Therefore the maximum preemption
latency is 10 ms.
The scenario I described essentially makes the need_resched flag *LOST*.
The maximum latency is 200 ms - an human perceivable amount. To me,
it is not even acceptable for desktop systems. Let alone embedded
systems.
----By the way, the fix I am suggesting is orthogonal to Ingo's low-latency work. Ingo's patch shortens the time periods when kernel runs without checking need_resched (in other words, shortens the preemption latency). My fix is to prevent need_resched flag from getting lost.
A kernel applying Ingo's patch but without my fix would still have the scenario I was describing and potentially up to 200 ms preemption latency. (I did not do a test, but pretty much sure that is the case.)
Jun
- 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 : Thu Mar 23 2000 - 21:00:31 EST