From owner-freebsd-arch@FreeBSD.ORG Sat Aug 25 22:20:45 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27F4416A417; Sat, 25 Aug 2007 22:20:45 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id C9C7413C461; Sat, 25 Aug 2007 22:20:44 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l7PMKenJ000627 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 18:20:41 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Aug 2007 15:23:10 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Kris Kennaway In-Reply-To: <20070824142952.GA24469@hub.freebsd.org> Message-ID: <20070825151913.S568@10.0.0.1> References: <20070818120056.GA6498@garage.freebsd.pl> <20070818155041.GY90381@elvis.mu.org> <20070818161449.GE6498@garage.freebsd.pl> <200708211403.29293.jhb@freebsd.org> <20070821191902.GA4187@garage.freebsd.pl> <20070821202136.GB4187@garage.freebsd.pl> <3bbf2fe10708221202h44b3258cyf5ca5e9b867ac0e7@mail.gmail.com> <20070824140927.GC14536@garage.freebsd.pl> <20070824142952.GA24469@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , Alfred Perlstein , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: Lockless uidinfo. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2007 22:20:45 -0000 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 : >>>> >>>> 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. Jeff > > Better to still do it in case that changes. > > Kris > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >