Messages in this thread | | | Date | Tue, 21 Mar 2000 18:43:33 +0100 | From | Jamie Lokier <> | Subject | Re: scheduler ignores need_resched flag in 2.2.x and 2.3.x? |
| |
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/
| |