Re: Comments on the KSE option

On Saturday 28 October 2006 11:51, Julian Elischer wrote:
> Alexandre "Sunny" Kovalenko wrote:
> > On Fri, 2006-10-27 at 18:25 -0700, Julian Elischer wrote:
> >> Alexandre "Sunny" Kovalenko wrote:
> >>> On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote:
> >>>> On Fri, 27 Oct 2006, Paul Allen wrote:
> >>>>>> From Julian Elischer <julian_at_elischer.org>, Fri, Oct 27, 2006 at
> >>>>>> 12:27:14PM -0700: The aim of the fair scheduling code is to ensure
> >>>>>> that if you, as a user, make a process that starts 1000 threads, and
> >>>>>> I as a user, make an unthreaded process, then I can still get to the
> >>>>>> CPU at somewhat similar rates to you.  A naive scheduler would give
> >>>>>> you 1000 cpu slots and me 1.
> >>>>>
> >>>>> Ah.  Let me be one of the first to take a crack at attacking this
> >>>>> idea as a mistake.
> >>>>
> >>>> No, it is POSIX.  You, the application, can write a program with
> >>>> system scope or process scope threads and get whatever you behavior
> >>>> you want, within rlimits of course.
> >>>>
> >>>> If you want unfair scheduling, then create your threads with
> >>>> system scope contention, otherwise use process scope.  The
> >>>> kernel should be designed to allow both, and have adjustable
> >>>> limits in place for (at least) system scope threads.
> >>>>
> >>>> Noone is saying that you can't have as many system scope threads
> >>>> as you want (and as allowed by limits), just that you must also
> >>>> be able to have process scope threads (with probably higher limits
> >>>> or possibly no limits).
> >>>
> >>> I might be missing something here, but OP was separating M:N (which is
> >>> what you are referring to above), and "fairness" (not giving process
> >>> with 1000 *system scope* threads 1000 CPU scheduling slots). As far as
> >>> I know the first one is POSIX and the second one is not.
> >>>
> >>> FWIW: as an application programmer who spent considerable amount of
> >>> time lately trying to make heavily multithreaded application run most
> >>> efficiently on 32-way machine, I would rather not have to deal with
> >>> "fairness" -- M:N is bad enough.
> >>
> >> no,  fairness is making sure that 1000 process scope threads
> >> do not negatively impact other processes.
> >> 1000 system  scope threads are controlled by your ulimit settings
> >> (Each one counts as a process.)
> >
> > 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.

David Xu