Comments on the KSE option
Matthew Dillon
dillon at apollo.backplane.com
Fri Oct 27 20:44:48 UTC 2006
I think the real issue here is that it is fairly difficult... probably
close to impossible in fact, to write a general purpose scheduler in
the kernel that can handle the types of extreme cases that can occur
when the kernel is made responsible for managing a user program's threads.
A better approach would be to make the kernel responsible for scheduling
cpu slots for programs, a far more manageable number, and if a program
wants to have thousands of threads on a 4-cpu system it (i.e. libthr)
should then have the responsibility of telling the kernel which
threads to pop into those slots at any given moment.
So, for example, if a machine has 4 cpus the kernel has 4 scheduling
slots it can fill. The kernel can apportion those slots with its current
scheduler technology. But if there is a program running on the system
that has thousands of threads, then why in the world would you want to
try to make the kernel scheduler deal with all those threads at once
when it only has 4 cpus to assign them to anyhow? So what you would
have instead would be the kernel saying to the program 'ok, I have 3
slots available for you at the moment' and make the program responsible
for telling the kernel which threads to run in those 3 slots. And
then a little while later the kernel might say 'I have 4 slots now',
or 'now I only have 2 slots available', etc etc.
This would then be a far more solvable problem for the kernel scheduler.
If you as the user then want the kernel to give the program with
thousands of threads more of the available cpu, it simply becomes a
matter of running the program at a lower NICE value.
-Matt
More information about the freebsd-current
mailing list