From owner-cvs-all Tue Jul 3 18:27: 6 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 20F5E37B403; Tue, 3 Jul 2001 18:26:58 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f641Qun40260; Tue, 3 Jul 2001 18:26:56 -0700 (PDT) (envelope-from dillon) Date: Tue, 3 Jul 2001 18:26:56 -0700 (PDT) From: Matt Dillon Message-Id: <200107040126.f641Qun40260@earth.backplane.com> To: Matthew Jacob Cc: Jake Burkholder , , Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_synch.c kern_condvar.c References: <20010703174807.R29024-100000@wonky.feral.com> 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 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' model, which I consider to be fatally flawed. It is a terrible idea to rip a perfectly happy kernel thread out from under itself just to satisfy some flawed notion that running the just-woken-up higher-priority process is more important. It may be *theoretically*, and it certainly can be argued for interrupts, but the reality is that you are actually slowing the whole fraggin machine down by blowing the L1 and L2 cpu caches and it is NOT something to be done lightly, certainly not in a general non-interrupt thread case. And you are opening yourself up to many, many potential degenerate wakeup/rip-up cases that never existed before. The solution is NOT to try to add yet more APIs to work around the inefficient results. The solution is to rip out the flawed concept that is causing this mess in the first place. mwakeup() is a fundamental and unnecessary obfuscation of the code. I brought this up at the kernel meeting and I am bringing it up again. If this continues then in another 6 months we are going to have dozens of wierd one-off API calls to handle the dozens of special cases these mechanisms are creating. Hell, this doesn't even cover the common case of holding more then one mutex! We already have a proliferation of mutex lock type calls. It is already bad enough right now. msleep() I can understand (at least it's flaw is similar to the flaw the spl() mechanism had in regards to thread sleep/wakeup synchronization). mwakeup() makes sense only in a very twisted way. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message