|Russell Francis||Feb 14, 2001 11:31 am|
|Kris Kennaway||Feb 14, 2001 7:10 pm|
|Seth Leigh||Feb 14, 2001 7:34 pm|
|Kris Kennaway||Feb 14, 2001 7:53 pm|
|Seth Leigh||Feb 14, 2001 9:01 pm|
|Nate Williams||Feb 14, 2001 9:36 pm|
|Kris Kennaway||Feb 14, 2001 9:43 pm|
|Terry Lambert||Feb 14, 2001 11:08 pm|
|Seth Leigh||Feb 14, 2001 11:20 pm|
|Seth Leigh||Feb 14, 2001 11:55 pm|
|Jason Evans||Feb 15, 2001 1:32 am|
|Nate Williams||Feb 15, 2001 9:06 am|
|Terry Lambert||Feb 15, 2001 3:35 pm|
|Nate Williams||Feb 15, 2001 3:41 pm|
|Terry Lambert||Feb 15, 2001 4:03 pm|
|Terry Lambert||Feb 15, 2001 4:08 pm|
|Terry Lambert||Feb 15, 2001 4:51 pm|
|Arun Sharma||Feb 15, 2001 5:19 pm|
|Arun Sharma||Feb 15, 2001 5:22 pm|
|Seth Leigh||Feb 15, 2001 5:53 pm|
|Nate Williams||Feb 15, 2001 7:17 pm|
|Kris Kennaway||Feb 15, 2001 9:16 pm|
|Russell Francis||Feb 15, 2001 9:31 pm|
|Yifeng Xu||Feb 15, 2001 9:33 pm|
|Arun Sharma||Feb 15, 2001 10:17 pm|
|Kris Kennaway||Feb 15, 2001 10:35 pm|
|Arun Sharma||Feb 15, 2001 11:01 pm|
|Seth Leigh||Feb 15, 2001 11:19 pm|
|Jordan Hubbard||Feb 16, 2001 2:06 am|
|Jacques A. Vidrine||Feb 16, 2001 9:06 am|
|Arun Sharma||Feb 16, 2001 10:45 am|
|Kris Kennaway||Feb 16, 2001 9:24 pm|
|Subject:||Re: possible problem with SMP?|
|From:||Seth Leigh (se...@pengar.com)|
|Date:||Feb 14, 2001 9:01:08 pm|
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.
At 07:54 PM 2/14/2001 -0800, you wrote:
On Wed, Feb 14, 2001 at 10:34:57PM -0500, Seth Leigh wrote:
To be honest, if FreeBSD can just get a threads library that uses a One to One ratio of threads to lwps (I am quite ignorant as to whether FreeBSD has the equivelant of the LWP structure, so just substitute process or whatever if I am off) I would be quite happy, and I am sure that performance would be just fine.
See the LinuxThreads port already mentioned.
I would be very much interested to see just how FreeBSD intends to Do Threading Right.
See the webpage already mentioned.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message