On Sun, 29 Oct 2006, Lucas James wrote: > I read what Paul said was that system scope threads have a different > "fairness" than processes. ie: > > If your application requires 1000 threads of execution, you can write it > three ways, with 1000 processes, 1000 system scope threads or 1000 process > scope threads (or a mix of the three). > > This whole "fairness" argument is about making system scope threads have the > same priority as process scope threads. It leaves out the process model. > > The real question here is: are we going to make system scope thread model > fair compared to process scope threaded model, or fair compared to the > separate processes model? > > Yes, the process scope threads are allways going to be the poor man with > regard to priority, but as the kernel doesn't see the threads you can't do > much about it. I think there are at least two core questions being discussed here: (1) Does the "fairness" model currently implemented in the KSE code mean well, but cause significant performance problems in practice for real-world applications? (2) Are the cost and complexity impacts of KSE in kernel architecture outweighed by the flexibility and performance benefits of M:N threading? Now is definitely the time for us to be discussing, measuring, experimenting, etc, because addressing the issues of higher concurrency for 7.0 will depend on having decided on a strategy for our scheduler. Robert N M Watson Computer Laboratory University of CambridgeReceived on Sun Oct 29 2006 - 08:24:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC