[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.021 / U:0.044 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site