SMP and setrunnable()- scheduler 4bsd

Julian Elischer julian at
Tue Jul 8 15:56:21 PDT 2003

On Tue, 8 Jul 2003, John Baldwin wrote:

> On 08-Jul-2003 Julian Elischer wrote:
> > It looks tp me that if we make a thread runnable
> > and there is a processor in the idle loop, the idle processor should be
> > kicked in some way to make it go get the newly runnable thread.
> > 
> > If the processors are halting in the idle loop however, it may take
> > quite a while for the new work to be noticed..
> > (possibly up to milliseconds I think)
> > 
> > Is there a mechanism to send an IPI to particular processors?
> > or is it just broadcast?  
> > 
> > 
> > I think we would be better served to alter idle_proc(void *dummy)
> > (or maybe choosethread()) to increment or decrement a count
> > of idle processors (atomically of course) so that 
> > setrunnable (or it's lower parts) can send that IPI
> > and get the idle processor into actioan as soon as a thread is
> > available.
> > 
> > I have not seen any such code but maybe I'm wrong....
> This is why HLT is not enabled in SMP by default (or at least was,
> it may be turned on now).  Given that the clock interrupts are
> effectively broadcast to all CPU's one way or another for all
> arch's (that I know of), you will never halt more than the interval
> between clock ticks on any CPU.

I think that this tells me that we shoould do as I suggest above.. :-)
i.e.  keep a count of idle processors (idlethreads running)
and if there is an idle processessor when a thread becomes available,
kick one of the idle processes to wake up. 

On a busy system it shuold never happen.

I guess we could make a scheduler method to do this if the scheduler
is going to choose which processor a thread will be run on,
and if the hardware doesn't support selecting a particular target, 
then we could broadcast it... I doubt the overhead would be more than
the reduction of latency for threaded apps.

> -- 
> John Baldwin <jhb at>  <><
> "Power Users Use the Power to Serve!"  -

More information about the freebsd-current mailing list