Re: Comments on the KSE option

From: Scott Long <scottl_at_samsco.org>
Date: Sat, 28 Oct 2006 23:11:42 -0600
Daniel Eischen wrote:
> On Sat, 28 Oct 2006, Matthew Dillon wrote:
> 
>>
>>    (2) Just because the POSIX scheduler implements all sorts of different
>>    scopes and priority schemes says NOTHING AT ALL about how programs
>>    operating under such a scheduler should be apportioned cpu relative
>>    to OTHER PROGRAMS WHICH ARE INDEPENDANTLY RUNNING ON THE SYSTEM.  
>> POSIX
>>    is an abstraction (or virtualization out of available resources),
>>    just like everything else.  If you try to treat it as a hard 
>> requirement
>>    the only result will be a broken system that might happily run 
>> everything
>>    else into the ground and stop allowing root ssh logins in order to
>>    accomodate a badly written POSIX program.  There are many third party
>>    applications that set POSIX priorities, in particular realtime
>>    priorities, that I'd rather they not actually use.  Most of these
>>    programs set these priorities based on the author's attempt to tune
>>    them on a single operating system (e.g. linux) and in a single 
>> operating
>>    environment.
>>
>>    All a program can ever really do when requesting POSIX scheduling
>>    resources is compete against itself.  It is the system operator, at a
>>    higher level, that must control how those resources compete with
>>    other programs.  That should be clear to everyone it is so obvious.
> 
> Actually, that's not quite true.  I assume you know the thing you
> left out:  system scope threads compete against all the other
> system scope threads in the system (from all applications, not
> just within one application).
> 

All this debate about the merits of process scope threads and fair
scheduling is great.  But tell me, who was working on making this stuff
work well quickly and reliably (i.e. work well)?  No one!  I don't care
what AIX or Solaris or what else may or may not have done, who was 
making this work well for FreeBSD?  Having a slow a thread subsystem is
a serious detriment, no matter how nice and flexible it looks on paper.

Scott
Received on Sun Oct 29 2006 - 04:12:14 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC