From owner-freebsd-arch Wed Jan 2 9: 8:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id AB5D737B41A; Wed, 2 Jan 2002 09:08:28 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g02H8AV96088; Wed, 2 Jan 2002 18:08:11 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g02H8Ttx043387; Wed, 2 Jan 2002 18:08:29 +0100 (CET)?g (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [10.1.7.11]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id g02H8SW12541; Wed, 2 Jan 2002 18:08:28 +0100 (CET) Received: (from ticso@localhost) by cicely9.cicely.de (8.11.6/8.11.6) id g02H8N613296; Wed, 2 Jan 2002 18:08:23 +0100 (CET) (envelope-from ticso) Date: Wed, 2 Jan 2002 18:08:22 +0100 From: Bernd Walter To: Michal Mertl Cc: Matthew Dillon , Bruce Evans , Mike Smith , Bernd Walter , arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <20020102170822.GB10762@cicely9.cicely.de> References: <200201012349.g01NnKA40071@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 02, 2002 at 03:53:55PM +0100, Michal Mertl wrote: > On Tue, 1 Jan 2002, Matthew Dillon wrote: > > :Not true. Atomic operations for counters are not needed on SMP systems > > :in at least the following cases: > > :- if there is a lock that prevents other processes from accessing the > > : counter > > :- if the counters are per-CPU. See previous mail by someone named msmith. > > : > > :Bruce > > > > Well, I'm not sure how I got on the Cc list but I agree with Bruce > > on this one. An SMP-synchronized counter increment is a ridiculous > > waste of time. They should be per-cpu and then we don't care *how* > > wide the counters are. Having programs like netstat, or our sysctl > > mechanism, aggregate the count values is easy. > > > > I don't know how much time will be wasted - my measurements on pII show > the atomic_ operations aren't that expensive. After Mike Smith cleared my understanding problem I agree. What I don't agree is that aggregating per CPU counters is easy. The data has to be pushed to the coherency point by each CPU to be readable by a single CPU, which doesn't happen for shure if you don't use specialiesed write methods and you may end up with old values. And you also have to deal with overflow issues if the updating is interruptable. I don't say it's a bad idea, but you have to be selective and it still may be the best choose for network counters. > There is a lot of counters and to have all of them for each processor > would waste a bit of memory but more importantly it would require some > structural changes - which may end up causing counters update being even > more expensive that atomic_. Using atomic ops is easy. Even if you > somewhere forget to use atomic_, if would still work - only with slight > chance the value become wrong. As long as your architecture has atomic_ capabilities for the needed size. > Anyway I'm just building world with my changes (only kernel and netstat > modified). I'm sure I missed several places to do some changes but at > least it runs and counts (I hope I'm wrong - I used egrep a lot). > > Do I understand correctly that on i386 I don't need anything special for > atomic_XXX_{rel|acq}? I implemented only one version (with cmpxchg8b - on > SMP with lock prepended) and others are just #defines to use the same > function. What I understood from Mikes mail is that only acq/rel pairs protect more that just the given value - others may not. On i386 this is not an issue because it's a coherent archicture. > My patch will break other archs but I'll look at their atomic.h and see if > I can make appropriate changes. I havn't seen one yet. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message