Stephen Warren wrote:
From: Con Kolivas [mailto:kernel@xxxxxxxxxxx] 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.
Attachment:
signature.asc
Description: OpenPGP digital signature