From owner-freebsd-arch@FreeBSD.ORG Thu May 20 20:45:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDC0F16A4CE for ; Thu, 20 May 2004 20:45:42 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F4343D2D for ; Thu, 20 May 2004 20:45:42 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i4L3jW5v012968; Fri, 21 May 2004 13:45:32 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i4L3jULS005620; Fri, 21 May 2004 13:45:31 +1000 Date: Fri, 21 May 2004 13:45:32 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer In-Reply-To: Message-ID: <20040521133502.Y4135@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org Subject: Re: atomic reference counting primatives. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 03:45:43 -0000 On Thu, 20 May 2004, Julian Elischer wrote: > This has been raised before but I've come across uses for it again and > again so I'm raising it again. > JHB once posted some atomic referenc counting primatives. (Do you still > have them John?) > Alfred once said he had soem somewhere too, and other s have commentted > on this before, but we still don't seem to have any. > > every object is reference counted with its own code and > sometimes it's done poorly. > > Some peiople indicated that there are cases where a generic refcounter > can not be used and usd this as a reason to not have one at all. Now we know that a generic reference counter would be even better for pessimizing FreeBSD than was first thought, since on P4's locked instructions are very expensive. See the thread about bridging. A pessimization by a factor of 2 or so has been achieved using little more than normal locking, since there are lots of lock/unlock pairs per packet and each lock and unlock takes hundreds (?) of cycles for the bus lock part and very little else. General atomic counters of any sort would take about half as lock as a lock/unlock pair (since they only need 1 lock, but would always needed it even if running in a locked region). The pessimizations from them could be broken using algorithms that don't need fine-grained locking. Bruce