lkml.org 
[lkml]   [2004]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: SCHED_RR and kernel threads
    Bill Davidsen wrote:
    > Stephen Warren wrote:
    >
    >>> From: Con Kolivas [mailto:kernel@kolivas.org] Stephen Warren writes:
    >>>
    >>>> I guess we could have most threads stay at SCHED_NORMAL, and just
    >>
    >>
    >> make
    >>
    >>>> the few critical threads SCHED_RR, but I'm getting a lot of push-back
    >>
    >>
    >> on
    >>
    >>>> this, since it makes our thread API a lot more complex.
    >>>
    >>>
    >>> Your workaround is not suitable for the kernel at large.
    >>
    >>
    >>
    >> You mean the official kernel.org kernel? I wasn't implying that the
    >> patch should be part of that!
    >>
    >> In our system we have literally EVERY single thread (kernel, user-space
    >> daemons, and user-space applications) all setup as SCHED_RR with
    >> identical priority at present, except a couple higher priority threads.
    >> We did this initially for user-space by replacing /sbin/init with a
    >> wrapper that set the scheduler policy and default priority, and verified
    >> that this was inherited by all daemons & application threads. Then, we
    >> found that the kernel threads could get starved in some situations,
    >> hence the kernel change.
    >>
    >> Our threading model dictates that every thread have a priority (so that
    >> the thread model is portable between Linux, embedded RTOSs etc.), and in
    >> Linux AFAIK, the only way to implement priorities is to use a real-time
    >> scheduling policy. Some threads do a lot of calculation. We want to make
    >> them equal (or probably, lower) priority to the kernel threads, so
    >> therefore the kernel threads must then be SCHED_RR.
    >>
    >> Can you elaborate on specific conditions that would cause the kernel
    >> threads to suck up unusual amounts of CPU time?
    >>
    >> In our application, keyboard processing is a real-time requirement, so
    >> if that is performed in a kernel thread, that kernel thread should be
    >> real-time. We basically want the control to insert e.g. the keyboard
    >> processing kernel thread into the middle of our priority hierarchy,
    >> rather than having it forced as the lowest possible priority.
    >
    >
    > Perhaps someone could comment on why the keyboard thread is NOT higher
    > priority? The whole functionality of SysReq key combinations would seem
    > to depend on actually seeing the strokes. I would cautiously suggest
    > that a priority control in /proc/sys might be a useful interface,
    > certainly compared to patching the kernel and rebuilding.
    >
    > Yes, I mean an option in the mainline kernel, so when debugging hangs
    > the keyboard could be used.
    >

    There is nothing stopping you from setting the priority and the
    scheduling policy from userspace in mainline.

    Cheers,
    Con
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 14:07    [W:0.026 / U:59.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site