Re: Comments on the KSE option

Matthew Dillon wrote:
>     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.

hey, wait, that's what the M:N library does!

> 
>     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