From owner-cvs-all Wed Jul 4 9:49: 0 2001 Delivered-To: cvs-all@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with SMTP id 007B237B427 for ; Wed, 4 Jul 2001 09:48:14 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25833 invoked from network); 4 Jul 2001 16:48:13 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Jul 2001 16:48:13 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200107040126.f641Qun40260@earth.backplane.com> Date: Wed, 04 Jul 2001 09:48:09 -0700 (PDT) From: John Baldwin To: Matt Dillon Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder , Matthew Jacob Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 -- 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