Date: Wed, 04 Jul 2001 09:48:09 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder <jake@FreeBSD.org>, Matthew Jacob <mjacob@feral.com> Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <XFMail.010704094809.jhb@FreeBSD.org> In-Reply-To: <200107040126.f641Qun40260@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Jul-01 Matt Dillon wrote:
>
>:On Tue, 3 Jul 2001, Jake Burkholder wrote:
>:
>:> jake 2001/07/03 17:32:51 PDT
>:>
>:> Modified files:
>:> sys/sys systm.h condvar.h
>:> sys/kern kern_synch.c kern_condvar.c
>:> Log:
>:> Implement mwakeup, mwakeup_one, cv_signal_drop and cv_broadcast_drop.
>:> These take an additional mutex argument, which is dropped before any
>:> processes are made runnable. This can avoid contention on the mutex
>:> if the processes would immediately acquire it, and is done in such a
>:> way that wakeups will not be lost.
>:
>:
>:I'm a bit confused by this last statement. Wakeups should never be lost
>:not matter what.
>:
>:I can see that it's possible you could get contention if the cv_signal
>:or wakeup causes a reschedule on another CPU right away. Is there any
>:empirical measurements showing this happening?
>:
>:Don't get me wrong- seems to be a useful variance, but we're starting to
>:look a bit like NT/Win32 here.
>:
>:-matt
>
> This call seems to implement for wakeup() what msleep() implements for
> tsleep(), and it makes sense in that context, but it is solving a problem
> by obfuscating the SMP code even more then it already is, all in the
> name of avoiding priority inversions using an 'instant-gratification'
Actually, Matt, this doesn't requrie preemption in order to be seen at all.
It's really quite simple:
cpu A cpu B
lock A ....
sleep on A ....
idle ....
lock A
wakeup A
block on A ....
unlock A , unblock thread that was on cpu A
lock A
With mwakeup, this becomes:
cpu A cpu B
lock A ....
sleep on A ....
idle ....
lock A
mwakeup A (drops A before doing actual wakeup)
lock A
Also, preemptive context switches in a fully preemptive kernel only take up
< ~10% of all context switches. (This is with a kernel that preempts in
setrunqueue() if the process is higher priority and will delay a preemption if
we are in a critical section until the outside critical_exit()). Also, note
that other successful multithreaded Unix kernels have all followed this method
(Tru64, IRIX, Solaris, etc.). Unfortunately our kernel is still not fully
preemption safe and has some bugs causing amd to sometimes hang in 'nanoslp'
when booting (very rare) and more often, causing the buffers to not get flushed
at shutdown time. However, the rather trivial patch is at
http://www.FreeBSD.org/~jhb/patches/preempt.patch for those who would like to
play along at home. Note that it's only been tested on UP x86, though there
are appropriate changes for SMP on both alpha and x86. Note that there is some
debugging cruft in the kern_shutdown.c code.
--
John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010704094809.jhb>