[lkml]   [2000]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] proposed scheduler enhancements and fixes
    Chris Wedgwood <> writes:

    > On Sat, Feb 26, 2000 at 11:30:15AM +0100, Manfred Spraul wrote:
    > > What about using SCHED_IDLE only for processes that are in user
    > > space? e.g. ret_with_reschedule calls a special
    > > "schedule_with_SCHED_IDLE()". As soon as a thread runs within
    > > kernel space, we ignore SCHED_IDLE.
    > This would only fix kernel-space deadlocks -- think about pthreads
    > and NSPR when you have userspace locking.

    Sorry, but this argument is fallacious. Sure, a SCHED_IDLE process can
    grab some userspace semaphore and then never get any time
    slices. However, it can also grab some userspace semaphore and then
    never release it, even now --- and the same effect results. It can also
    be SIGSTOPped, which does the same thing again (and also doesn't affect
    stuff in kernel space, for obvious reasons).

    We can safely assume that kernel space will not do that, but we cannot
    assume that userspace won't.

    The only difference is that now users can trigger this effect, as well
    as program bugs.

    I agree that a process in kernel space must always be non-SCHED_IDLE, or
    perhaps that SCHED_IDLE is treated as SCHED_OTHER as long as a process
    is in kernel mode. But banning it in userspace because of userspace
    locks is wrong. (Consider that most processes that are likely to be
    SCHED_IDLE will spend nearly all their time in userspace, so banning
    kernel-space SCHED_IDLE will have negligible effect on the performance
    improvement achieved by this code.)

    (IMHO, of course. ICBW.)

    You must have some, but I don't see any evidence of it.'
    --- Craig Hardie flames a luser recruitment consultant
    advertising `Microsoft based solutions' on uk.comp.os.linux

    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:56    [W:0.021 / U:1.064 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site