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_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >Received on Tue Jul 08 2003 - 13:56:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:14 UTC