OK, having read this, I am still not sure of how this scheme is any better than the way it is done, for example, in Solaris, with the exception that this scheme will prevent a single process from competing unfairly with other processes simply by creating a large number of threads. To be honest, if assuring that individual processes compete with each other fairly for cpu time irrespective of the number of threads created is very important, then running processes under the Solaris Resource Manager scheduling class under different Lnodes sounds like a perfectly reasonable way to do it. In fact, I would imagine that it would be possible simply to implement a new scheduling class that eliminates the unfair competition between processes but avoids most of the complexity of the Solaris Resource Manager simply by calculating the priorities of all of the runnable lwps on the system such that no single process' lwps get more time on the cpus in general than is fair. Fair in this case could simply be that no single process gets more time than any other process which is able to use the same number of cpus. Ie: two processes with two threads would get equal time, a process with 4 threads would get around twice as much time as one with only 2 threads on a 4-way machine, or a process with 4 threads would get around four times as much time as one with 1 thread. For a 4-way machine, the scheme could simply make sure that no process got more than 4 times as much cpu time as any other process, even if one process had 20 threads and the other had only 1.

Solaris allows you to create such a scheduling class as a loadable module that would do things just as fairly as your mind can dream up. In fact, it was a 3rd party that apparently wrote the Solaris Resource Manager scheduling class as a commercial product, and Sun liked it so much they bought it.

Anyhow, perhaps I just haven't seen the light. I should probably go back and re-read the paper on the web site, since I just don't really see how this is "The Right Way" over how Solaris does this, for example.

One question I have is this. Since I assume you aren't going to be messing with the system clock interupts, but you seem to be adding your own timers to the UTS to handle preemption at the user level, aren't you guys adding more wasted overhead dealing with timer interupts? Ie: you keep all the existing kernel-level timer interupts, but add a lot of timer signals and such going up to the UTS? At least with a One to One scheduling model, you only have as much timer-related overhead as the system currently has, and with per-process run queues, fine lock granularity throughout the system allowing for multiple cpus to be running in the scheduler at the same time, etc., letting the kernel scheduler do all the work of scheduling the lwps doesn't seem to be too bad.

I don't see the logic in the argument "letting the kernel scheduler handle the scheduling of all the threads (via lwps) is bad, because it overloads the kernel scheduler, so we are going to do all of this thread scheduling using a user-level thread scheduler". If you can write a user-level thread scheduler that won't get "overloaded" by a large number of threads, why can't you just write the kernel-level scheduler the same way? I suppose if the answer is that the existing FreeBSD scheduler is just too clumsy to provide good scalability over multiple cpus and a large number of runnable lwps, then wouldn't the first job be to improve the scheduler, rather than simply try to shift all the load into a UTS?

I look forward to being enlightened.

Seth

At 07:54 PM 2/14/2001 -0800, you wrote:

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message