1:1 threading.

[Igor Sysoev]

On Thu, 27 Mar 2003, Jeff Roberson wrote:

>The ksegrp argument is questionable anyway.  In both ULE and 4bds each KSE
>gets its own quantum.  The KSEGRP holds the static priority and the
>dynamic user priority which is calculated based on the behavior of the
>whole process.  This causes all threads in the process to be penalized for
>using cpu at the same rate as a single threaded process using an
>equivalent amount of cpu would be.

Why should multi-threaded process get more CPU time then single threaded
if they both have the same base priority ?  CPU time should be given
based on a process priority not a number of its threads.

>The effects are less because each thread/kse is given as big of a quantum
>as each full process would.  I'm not sure if this is a bug or a feature.

It's not a bug or a feature.  It's the right thing.

>In my opnion the ksegrp is not totally hashed out. I think you may forget
>that I have done a fair amount of work on schedulers in freebsd and I do
>understand the ramification of the decision that I made.  I do not think
>this at all important to have correct prior to having real users using
>real threads.

As I understand KSEGRP was designed with M:N model in mind.  If you
have M threads mapped to N KSEs then all these KSEs should have the same
priority.  The second KSEGRP capability is to limit a number of KSEs to
a number of CPUs.  It's usefull for M:N model because KSE is almost
never (I believe) blocked and always ready to run (if not parked).

For 1:1 model KSEGRP is not theoreticaly needed because you can set
priority (theoreticaly) directly in KSE and you do not need to limit
a number of KSEs to a number of CPUs.  If the thread blocks then its KSE
blocks too.

But I think for design completeness you should use KSEGRP to store KSE's
priority in 1:1 model.


Igor Syseov
http://sysoev.ru/en/