Now that I've thought a bit more on this, I came up with following
enhancements to the original idea: (and haven't yet looked at VSTa, perhaps I
should soon..)
There should be one default scheduler in the kernel, and in addition other
schedulers (like QNX-scheduler, evolutionary scheduler, ...) as modules.
Well, perhaps two schedulers in kernel, "normal" and "round robin"
(for realtime tasks).
The whole tree would be visible in /proc/sched_tree (and with sysctl) and
you could do modifications with standard tools. This way users could just
"mkdir" their own nodes and have, for example, 3 processes running with the
qnx scheduler, 6 with the normal scheduler and these nodes themselves
scheduled with a round-robin scheduler. This particular example doesn't make
any sense, but there are other things that do (real-time processes, idle
processes, ..). The number of nodes a user could create would be limited,
of course (otherwise any user could cause a DoS)..
For example, you could do:
# cd /proc/sched_tree/cpu_all/other/uids/0/
# cat scheduler
default
# cat /proc/sched_tree/schedulers
default
round-robin
qnx
# echo "qnx" >scheduler
# insmod my_scheduler.o
# cat /proc/sched_tree/schedulers
default
round-robin
qnx
my-scheduler
# cd ..
# mv 0/* /proc/sched_tree/cpu_all/real-time/uids/0
# mv 500/13342 /proc/sched_tree/cpu_all/real-time/procs
# tree_setprio /proc/sched_tree/cpu_all/real-time/procs 30
(note: this would allow root to do "mv 123/* 312/", which wouldn't make any
sense :} but still demonstrates that the scheduler tree is completely
separate from the process tree)
Yet another idea struck me while I was writing this: If you could tell
kernel "don't migrate processes from one CPU to another", you could do it in
user-space (perhaps there's no point in it, but..) :)
I haven't yet thought how to implement the user-scheduling, but perhaps it
would be a module that creates the "/uid" dirs when it's insmoded..
Note that fork() places the new process under the same node where the parent
was, so it would suffice to move all processes under their proper /uid/xxx/
node.. Except for real-time processes, perhaps.
An exception is setuid(), because when a user logs in, the process should be
placed to an appropriate uid directory. There probably should be
"tree_root->place_process(task_struct *foo)" which would search the tree in
a well defined order to find where to put the process. Each parent node
would have this function, so the user-scheduler module would just override
the default for the /uid directories.
Does it sound like it would cause too much overhead?
-- Real Users are afraid they'll break the machine -- but they're never afraid to break your face.