Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Oct 2006 18:25:05 -0700
From:      Julian Elischer <julian@elischer.org>
To:        "Alexandre \"Sunny\" Kovalenko" <Alex.Kovalenko@verizon.net>
Cc:        Daniel Eischen <deischen@freebsd.org>, Paul Allen <nospam@ugcs.caltech.edu>, current@freebsd.org
Subject:   Re: Comments on the  KSE option
Message-ID:  <4542B171.8050601@elischer.org>
In-Reply-To: <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net>
References:  <45425D92.8060205@elischer.org>	<20061027201838.GH30707@riyal.ugcs.caltech.edu>	<Pine.GSO.4.64.0610271634160.7105@sea.ntplx.net> <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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.)





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4542B171.8050601>