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).
It makes a fair amount of sense.
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.