![]() | |||||||||||||
Messages in this thread |
William Lee Irwin III wrote: > William Lee Irwin III wrote: >>> I'd further recommend making priority levels accessible to kernel threads >>> that are not otherwise accessible to processes, both above and below >>> user-available priority levels. Basically, if you can get SCHED_RR and >>> SCHED_FIFO to coexist as "intimate scheduler classes," then a SCHED_KERN >>> scheduler class can coexist with SCHED_OTHER in like fashion, but with >>> availability of higher and lower priorities than any userspace process >>> is allowed, and potentially some differing scheduling semantics. In such >>> a manner nonessential background processing intended not to ever disturb >>> userspace can be given priorities appropriate to it (perhaps even con's >>> SCHED_IDLEPRIO would make sense), and other, urgent processing can be >>> given priority over userspace altogether. > > On Thu, Apr 19, 2007 at 09:50:19PM +1000, Peter Williams wrote: >> This is sounding very much like System V Release 4 (and descendants) >> except that they call it SCHED_SYS and also give SCHED_NORMAL tasks that >> are in system mode dynamic priorities in the SCHED_SYS range (to avoid >> priority inversion, I believe). > > Descriptions of that are probably where I got the idea (hurrah for OS > textbooks). And long term background memory. :-) > It makes a fair amount of sense. Yes. You could also add a SCHED_IA in between SCHED_SYS and SCHED_OTHER (a la Solaris) for interactive tasks. The only problem is how to get a task into SCHED_IA without root privileges. > Not sure what the take on > the specific precedent is. The only content here is expanding the > priority range with ranges above and below for the exclusive use of > ultra-privileged tasks, so it's really trivial. Actually it might be so > trivial it should just be some permission checks in the SCHED_OTHER > renicing code. Perhaps. Peter -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-04-20 06:19 [from the cache] ©2003-2008 | |||||||||||||