[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: scheduler ignores need_resched flag in 2.2.x and 2.3.x? 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.123 / U:3.116 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site