is at rambler-co.ru
Thu Mar 27 22:29:03 PST 2003
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
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
But I think for design completeness you should use KSEGRP to store KSE's
priority in 1:1 model.
More information about the freebsd-arch