Thor Lancelot Simon wrote:
> On Tue, Sep 19, 2006 at 06:14:59PM +0100, David Laight wrote:
>   
>> On Tue, Sep 19, 2006 at 01:30:56AM +0200, Daniel Sieger wrote:
>>     
>>> Hi all,
>>> ok, I would like to get some suggestions about how to further improve
>>> the scheduler. The first thing that comes to my mind is to design a
>>> general scheduling API that allows for the implementation of different
>>> algorithms and/or models. FreeBSD did a similar job, IIRC. So, the
>>> next steps would be i) to define the API itself and ii) to separate
>>> the traditional 4.4BSD scheduler from kern_synch.c.
>>>
>>> Any comments/suggestions?
>>>       
>> One 'really useful feature' that any change should allow for is
>> process affinities (ie tying a process to a physical cpu).
>>     
>
> I should note that we have already been offered a patch to do this, by
> Christian Limpach.  It was rejected -- to my utter disbelief -- by an
> influential developer because, since it packed "which run queue am I
> on" into an integer with one bit per CPU, it would require later revision
> to accomodate systems with more than 32 processors.
>
> I think this is a canonical example of how the best is the enemy of the
> good.  ;-)  But perhaps when I get a 32-chip system, I will feel otherwise.
>   

Heh.  Well, it should have been altered to use a 64-bit integer.

32-core systems are only a heartbeat away from being common place, and
I've worked with Solaris on systems that have considerably more cpus. 
(up to 144). 

That said, it might have been better to have committed it first, and
fixed it later to support large SMP systems.   Does NetBSD support any
such systems now?  (Can you bring up NetBSD on a 64-way E10k?  Not right
now -- no sparcv9 SMP.  And maybe its not interesting anyway, given the
current state of our SMP scalability.)

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191