From owner-cvs-all Wed Jul 4 10:39:30 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 73FBF37B401; Wed, 4 Jul 2001 10:39:23 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f64HdN945537; Wed, 4 Jul 2001 10:39:23 -0700 (PDT) (envelope-from dillon) Date: Wed, 4 Jul 2001 10:39:23 -0700 (PDT) From: Matt Dillon Message-Id: <200107041739.f64HdN945537@earth.backplane.com> To: John Baldwin Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder , Matthew Jacob Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ References: 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 :> :> 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 Huh? In the above example, why not simply release A before calling the wakeup function in the above example? mwakeup is not required at all. You may have to interlock sleeps, but you certainly do not have to interlock wakeups. Try presenting another example. In the non-preemptive case, on a UP system, the first task is allowed to wakeup the second, then unlock, then sleep, and then will switch to the second task. All without any need for a mwakeup() function. In the preemptive case, on a UP system, you have to have mwakeup() to avoid the two extra context switches. In the non-preemptive case, on a MP system, the scheduling overhead will take far longer then it takes the original thread to release the mutex so it does not matter whether the mutex is released before or after the wakeup. In the preemptive case, on a MP system, there isn't going to be any significant difference except that you will wind up blowing the L1 and L2 cpu caches to do the preemption if the system happens to be heavily loaded... precisely the wrong time, because a heavily loaded system is in a situation where you want the system to operate as efficiently as possible. You are already eating time slices due to the load, getting a kernel thread to run a few microseconds earlier is not going to make a damn bit of difference in regards to interactive responsiveness and yet to get those few microseconds you are willing to blow up the cpu caches AND eat the extra switching overhead. It makes no sense. - My assertion is that mwakeup() is solving a problem created by the preemption in the first place and that assertion still holds true. This preemption stuff is going to turn performance tuning into a nightmare. No, I take that back. It has ALREADY turned performance tuning into a nightmare and it is only going to get worse. By the 5.0 release we are going to have dozens upon dozens of special case API calls like mwakeup(). We already have too many. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message