Date: Wed, 15 May 2002 08:21:46 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: current@FreeBSD.org Subject: RE: preemption across processors Message-ID: <XFMail.20020515082146.jhb@FreeBSD.org> In-Reply-To: <200205151106.g4FB6Z3i059559@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15-May-2002 Seigo Tanimura wrote:
> Currently, a new runnable thread cannot preempt the thread on any
> processor other than the thread that called mi_switch(). For
> instance, we do something like the following in _mtx_unlock_sleep():
>
> --- v --- _mtx_unlock_sleep() --- v ---
> setrunqueue(th_waken_up);
> if (curthread->preemptable && th_waken_up->priority < curthread->priority) {
> setrunqueue(curthread);
> mi_switch();
> }
> --- ^ --- _mtx_unlock_sleep() --- ^ ---
>
> If the priority of curthread is higher than th_waken_up, we cannot run
> it immediately even if there is another processor running a thread
> with a priority lower than th_waken_up. th_waken_up should preempt
> that processor, or we would end up with a priority inversion.
>
> Maybe we have to dispatch a runnable thread to the processor running
> a thread with the lowest priority. Solaris seems to take the
> following steps to do that:
>
> 1. If a new thread has slept for longer than 3/100 seconds (this
> should be tunable), linearly search the processor running a thread
> with the lowest priority. Otherwise, choose the processor that ran
> the new thread most recently.
>
> 2. Make an inter-processor interrupt to the processor chosen in 1.
>
> 3. The chosen processor puts its current thread back to the dispatch
> queue and performs a context switch to run the new thread.
>
> Above is only a rough sketch. We have to watch out for a race of
> inter-processor interrupts and a processor entering a critical section.
>
> If no one is working on preemption across processors, I would like to
> see if I can do that.
I actually think that the little gain this brings isn't worth the extra
effort involved personally. We don't have to get things perfect, getting
them reasonably close is good enough for some things. However, that is
only my opinion. If the code to support this is relatively clean and
simple with low-impact in the normal case then I would support it. However,
there are several tricky race conditions here so I'm not sure it can be
done simply.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020515082146.jhb>