Subject: Re: Moving scheduler semantics from cpu_switch() to kern_synch.c
To: matthew green <mrg@eterna.com.au>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 09/21/2006 10:09:22
matthew green wrote:
>    
>    > it just seems suboptimal to have to set a flag in every cpu_info when
>    > there is a (random) process to run.
>    
>    You would not set it in every cpu_info... the idea is that processes  
>    would be "bound" to CPUs to eliminate the cache thrash that we  
>    currently have because processes can migrate between CPUs randomly.   
>    We're talking about per-CPU run queues, here.
>
>
> so every process is bound to a cpu?  i guess i don't understand how
> this works to avoid cpus idling while lwps are waiting for "their"
> cpu to become free...  who runs a new process first?  right now it
> is who ever tries to first.
>
>
> .mrg.
>   

Can this be managed with scheduling priorities?  I.e. you take a -5 (or
some other random constant) hit against your scheduling priority when
your process is being considered for scheduling on a CPU other than your
"preferred" one?  It won't be perfect, but I imagine it would seriously
help the thrash.  And you still have the idle thread at the absolute
bottom level, so IDLE is only ever run on a processor if _no_ thread can
be scheduled on it.

-- 
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