Re: SCHED_RR and kernel threads

[Bill Davidsen <davidsen@tmr.com>]

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.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me