Date: Mon, 27 Aug 2007 09:14:59 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Attilio Rao <attilio@freebsd.org>, Alfred Perlstein <alfred@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: Lockless uidinfo. Message-ID: <200708270915.00516.jhb@freebsd.org> In-Reply-To: <20070825151913.S568@10.0.0.1> References: <20070818120056.GA6498@garage.freebsd.pl> <20070824142952.GA24469@hub.freebsd.org> <20070825151913.S568@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 25 August 2007 06:23:10 pm Jeff Roberson wrote: > > On Fri, 24 Aug 2007, Kris Kennaway wrote: > > > On Fri, Aug 24, 2007 at 04:09:27PM +0200, Pawel Jakub Dawidek wrote: > >> On Wed, Aug 22, 2007 at 09:02:53PM +0200, Attilio Rao wrote: > >>> 2007/8/21, Pawel Jakub Dawidek <pjd@freebsd.org>: > >>>> > >>>> New patch is here: > >>>> > >>>> http://people.freebsd.org/~pjd/patches/uidinfo_waitfree.patch > >>> > >>> --- sys/ia64/include/atomic.h.orig > >>> +++ sys/ia64/include/atomic.h > >>> @@ -370,4 +370,15 @@ > >>> > >>> #define atomic_fetchadd_int atomic_fetchadd_32 > >>> > >>> +static __inline u_long > >>> +atomic_fetchadd_long(volatile u_long *p, u_long v) > >>> +{ > >>> + u_long value; > >>> + > >>> + do { > >>> + value = *p; > >>> + } while (!atomic_cmpset_64(p, value, value + v)); > >>> + return (value); > >>> +} > >>> + > >>> > >>> In cycles like those, as you get spinning, I would arrange things in > >>> order to do a cpu_spinwait(). Like this: > >>> > >>> for (;;) { > >>> value = *p; > >>> if (atomic_cmpset_64(p, value, value + v)) > >>> break; > >>> cpu_spinwait(); > >>> } > >> > >> In this case there is no difference as this is MI ia64 code and > >> cpu_spinwait() is defined as /* nothing */ there. As a general rule, > >> this might be a good idea. > > > I don't know that these kinds of loops really need cpu_spinwait(). If you > consider that the loop condition is only triggered if a single instruction > overlaps with another thread and one thread always wins, the number of > cases where we restart more than once is negligible. I believe pjd's test > that was artificially constructed to cause as much contention as possible > still only saw 30% loop once. > > This is contrasted with spin-wait code where no-one is making any progress > while a lock is held. I think this just adds complexity to the code > without any advantage. > > The cpu_spinwait() function is meant to stop one HTT core from starving > another that is holding a lock. In this case there is no lock and so > there is no starvation possible. Actually by spinwaiting you may increase > the chance for a second loop. Agreed. cpu_spinwait() is for when we know we will have to wait at least for a little while. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708270915.00516.jhb>