Re: Comments on the KSE option

Robert Watson wrote:

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.


I'd like to add

(3) Who is committed to maintaining and improving the M:N and KSE architectures for the long term? THR and 1:1 has an active and committed maintainer right now, KSE does not. Whether KSE is 'better'
is purely academic if no one is willing to actually make it work.

Scott

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Comments on the KSE option
    ... The aim of the fair scheduling code is to ensure that if you, as a user, ... system scope contention, otherwise use process scope. ... limits in place for system scope threads. ... so in fact M:N is usually M user threads over over some number like 4 or 8 kernel threads plus the number of threads waiting for IO. ...
    (freebsd-current)
  • Re: Comments on the KSE option
    ... The aim of the fair scheduling code is to ensure that if you, as a user, ... system scope contention, otherwise use process scope. ... limits in place for system scope threads. ... are enacted using N kernel schedulable entities. ...
    (freebsd-current)
  • Re: Comments on the KSE option
    ... :system scope contention, otherwise use process scope. ... :limits in place for system scope threads. ...
    (freebsd-current)
  • Re: Comments on the KSE option
    ... 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. ... This whole "fairness" argument is about making system scope threads have the same priority as process scope threads. ... are we going to make system scope thread model fair compared to process scope threaded model, or fair compared to the separate processes model? ...
    (freebsd-current)
  • Re: Comments on the KSE option
    ... The aim of the fair scheduling code is to ensure that if you, as a user, ... system scope contention, otherwise use process scope. ... limits in place for system scope threads. ...
    (freebsd-current)