Date: Wed, 2 Jan 2002 18:08:22 +0100 From: Bernd Walter <ticso@cicely9.cicely.de> To: Michal Mertl <mime@traveller.cz> 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: <20020102170822.GB10762@cicely9.cicely.de> In-Reply-To: <Pine.BSF.4.41.0201021003580.18429-100000@prg.traveller.cz> References: <200201012349.g01NnKA40071@apollo.backplane.com> <Pine.BSF.4.41.0201021003580.18429-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020102170822.GB10762>