From owner-freebsd-current Mon Feb 18 12: 0:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id A9F8537B402 for ; Mon, 18 Feb 2002 12:00:38 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020218200038.GKFM1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Mon, 18 Feb 2002 20:00:38 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA52841; Mon, 18 Feb 2002 11:50:10 -0800 (PST) Date: Mon, 18 Feb 2002 11:50:09 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: current@freebsd.org Subject: Re: Patch to improve mutex collision performance In-Reply-To: <200202181912.g1IJCGK32122@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 18 Feb 2002, Matthew Dillon wrote: [...] > > It turns out that the two processes got into an extremely non-optimal > contested/sleep/wakeup situation, even though they do not actually have > to sleep on Giant in this situation. > > The solution is to allow _mtx_lock_sleep() to spin instead of sleep in > the situation where: (1) there are no runnable processes other then > the ones already running on a cpu, (2) interrupts are enabled, and > (3) the mutex in question is not contested (to avoid starving the thread > contesting the mutex). In this case we can spin. it's possible John's preemption code may also handle this.. > > -Matt > > Index: kern/kern_mutex.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_mutex.c,v > retrieving revision 1.80 > diff -u -r1.80 kern_mutex.c > --- kern/kern_mutex.c 18 Feb 2002 17:51:47 -0000 1.80 > +++ kern/kern_mutex.c 18 Feb 2002 19:11:17 -0000 > @@ -287,7 +287,9 @@ > _mtx_lock_sleep(struct mtx *m, int opts, const char *file, int line) > { > struct thread *td = curthread; > +#if 0 > struct ksegrp *kg = td->td_ksegrp; > +#endif > > if ((m->mtx_lock & MTX_FLAGMASK) == (uintptr_t)td) { > m->mtx_recurse++; > @@ -312,6 +314,22 @@ > * the sched_lock. > */ > if ((v = m->mtx_lock) == MTX_UNOWNED) { > mtx_unlock_spin(&sched_lock); > continue; > } > + > + /* > + * Check to see if there are any runnable processes. If > + * there aren't and nobody is contesting the mutex (to avoid > + * starving a contester) and interrupts are enabled, then > + * we can safely spin. > + * > + * This prevents a silly-sleep-flip-flop situation on SMP > + * systems where two running processes need Giant (or any > + * other sleep mutex). > + */ > + if (td->td_critnest == 0 && (v & MTX_CONTESTED) == 0 && > + procrunnable() == 0) { > + mtx_unlock_spin(&sched_lock); > + continue; > + } I can't see any major problem with this but I can't help thinking that there must be one.. on UP the question is: "who is going to release the lock if no-one is runnable?" can you detail in more clarity the flip-flopping you were seeing? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message