Date: Wed, 2 Jan 2002 18:27:10 +0100 (CET) From: Michal Mertl <mime@traveller.cz> To: Bernd Walter <ticso@cicely9.cicely.de> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, Bernd Walter <ticso@cicely8.cicely.de>, <arch@FreeBSD.ORG> Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <Pine.BSF.4.41.0201021811300.58276-100000@prg.traveller.cz> In-Reply-To: <20020102170822.GB10762@cicely9.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Jan 2002, Bernd Walter wrote: > 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. > The patch at http://home.eunet.cz/mime/atomic_t.patch.0201.gz (i386 only at the moment) tries to do one thing - define atomic_t type (can be counter_t or so) which is either 32 or 64 bit (64 bit only on >=586). The counters are of type atomic_t and are accessed with atomic_op_max (better name welcome - maybe atomic_op_long_plus (meaning it's at least 32 bits) functions which are rewritten to atomic_op_int or atomic_op_quad. Other architectures should only need to add to /sys/arch/include/atomic.h the defines for atomic_t and atomic_op_max. There are 3 points in patch (identifiable by 'mime XXX ??') which may be problems in original code. The line 295 at /sys/netipx/ipx_ip.c is I think bug. I tried to read the values and they seem ok. > > 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. > What about other archs? I may be i386 centric. We probably need the operations to be SMP-secure and if other arches don't do the coherency automatically Matt and others may be right that the updates could be expensive then. > > 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. > Ok ok. I wanted to make really sure it's good but above you have the URL. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.41.0201021811300.58276-100000>