Re: Comments on the KSE option

At 12:06 PM +0800 10/28/06, David Xu wrote:
>On Saturday 28 October 2006 11:51, Julian Elischer wrote:
>  > Alexandre "Sunny" Kovalenko wrote:
>  > >
>  > > I apologize for misinterpreting your words. But then, if I have
>  > > M:N set to 10:1, I would expect application with 1000 process
>  > > scope threads to have as many CPU slots as 100 processes, or,
>  > > if I have 10 system scope threads and 990 process scope threads,
>  > > I would expect application to have as many CPU slots as 109
>  > > processes. Is this what you refer to as "fairness"?
>  >
>  > M:N is not a ratio, but rather the notation to say that M user
>  > threads are enacted using N kernel schedulable entities (kernel
>  > threads).  Usually N is limited to something like NCPU kernel
>  > schedulable entities running at a time. (not including sleeping
>  > threads waiting for IO)
>  > (NCPU is the number of CPUs).
>  >
>  > so in fact M:N is usually M user threads over over some number
>  > like 4 or 8 kernel threads (depending on #cpus) plus the number
>  > of threads waiting for IO.
>  >
>>  Julian
>
>As you are emphasizing fairness, I must say I don't believe fairness
>in libpthread either, I don't think writting a fairness scheduler is
>an easy work, does kernel have made fairness for threads in same
>ksegrp, so does libpthread's userland scheduler ? they don't, it can
>make threads in same ksegrp misbehaviored, so what we have done is
>still process scheduling fairness even there is ksegrp in kernel,
>and now sacrificed fairness between threads.

I think we have different ideas of what is the goal is with this
claim of "fairness".

If I understand it right, it is *not* that some static code in the
kernel is going to decide which applications are fair and which ones
are not fair.  IIIRC, what Julian wants to do is provide a way that
the administrator can make that decision.  The administrator will
have a way to throttle some thread-crazy process, but only if the
*administrator* wants to do that.

If the machine is for a single user, then that user will probably
set "N" to a high value.  But if the machine has a lot of users on
it, then the administrator of that machine may want to set "N" to
the number of CPU's on the system, or maybe the number of CPU's
minus 1.  And if the users don't like that, then they can go buy
their own damn machine instead of using the machine someone else
bought and is allowing them to access for free.

At RPI we have both kinds of machines.  Machines owned by a single
user, and machines which have multiple students ssh'ed into at the
same time.  I can see wanting to throttle thread-crazy processes on
some machines, and not wanting any throttling at all on others.

...but it has been a few years since the presentation that I remember
Julian giving about this, so maybe I am not remembering it correctly.
I do remember that whatever it was, it sounded pretty reasonable at
the time.   :-)

-- 
Garance Alistair Drosehn            =   gad_at_gilead.netel.rpi.edu
Senior Systems Programmer           or  gad_at_freebsd.org
Rensselaer Polytechnic Institute    or  drosih_at_rpi.edu