Messages in this thread | | | Date | Thu, 11 Nov 2004 07:40:26 +1100 | From | Con Kolivas <> | Subject | Re: 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] | |