yodaiken@fsmlabs.com wrote:
> > Note that even the global variable still has the ret_from_sys_call race.
>
> Note that that "race" is not necessarily bad. It trades latency for
> throughput and avoids some possible nasty loops.
The trade here doesn't seem to benefit anything, and there are no loops
to avoid.
There's simply a window after checking ret_from_syscall and before iret
where a reschedule is lost until that path is reached again. It only
occurs when an interrupt occurs in kernel space and the interrupt sets
need_resched during those few instructions. It's quite easy to detect
and fix up.
> You really don't want a situation where the kernel is working hard trying to
> figure out exactly the most optimal process to run and dithering about it
> while no real work gets done.
The kernel doesn't dither -- this only happens when you receive an
interrupt that wakes up a higher priority task, the code that's
interrupted is within 7 particular kernel space instructions (on x86),
and the interrupt sets need_resched when it was not set before.
It's rare but happens occasionally.
For it to loop, you need it to happen repeatedly. It must be a rapid
cascade of interrupts waking up successively higher priority tasks.
Each interrupt has to arrive exactly a few cycles before the previous
interrupt handler is about to return to userspace -- if that's
happening, userspace is already broken.
-- 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 : Thu Mar 23 2000 - 21:00:33 EST