Re: SCHED_RR and kernel threads

From: Bill Davidsen
Date: Wed Nov 10 2004 - 15:28:03 EST


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.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/