Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Jul 2006 10:58:12 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-current@freebsd.org
Cc:        Oliver Fromme <olli@lurza.secnetix.de>
Subject:   Re: vmstat's entries type
Message-ID:  <200607271058.13055.jhb@freebsd.org>
In-Reply-To: <200607251254.k6PCsBef092737@lurza.secnetix.de>
References:  <200607251254.k6PCsBef092737@lurza.secnetix.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 25 July 2006 08:54, Oliver Fromme wrote:
> John Baldwin <jhb@freebsd.org> wrote:
>  > On Sunday 23 July 2006 20:03, Sten Daniel S=F8rsdal wrote:
>  > > sthaug@nethelp.no wrote:
>  > > > > > One approach that we could use for 64-bit counters would be to=
=20
just
>  > > > > > use 32-bits one, and poll them for overflow and bump an overfl=
ow
>  > > > > > count.  This assumes that the 32-bit counters overflow much le=
ss=20
often
>  > > > > > than the polling interval, and easily triples the amount of=20
storage
>  > > > > > for each of them...  It is ugly :-(
>  > > > > >=20
>  > > > > What's wrong with the add+adc (asm) approach found on any i386?
>  > > >=20
>  > > > Presumably the fact that add + adc isn't an atomic operation. So if
>  > > > you want to guarantee 64 bit consistency, you need locking or=20
similar.
>  > > >=20
>  > >=20
>  > > Would it not be necessary to do this locking anyway?
>  > > I don't see how polling for overflow would help this consistency.
>  > > Are both suggestions insufficient?
>  >=20
>  > I actually think that add + adc is ok for the case of incrementing sim=
ple=20
>  > counters.  You can even do 'inc ; addc $0'
>=20
> (I'm familiar with asm programming, but I'm not a low-level
> threading or SMP expert, so please excuse me if this is a
> dumb question ...)
>=20
> If you just do add+adc (or inc+adc) and another thread (on
> the same or different processor, I don't know) happens to
> read the counter value at the same time (i.e. after the
> lower 32bit have overflowed, but before the upper 32bit get
> incremented), then that other thread would get a value
> that's off by 2^32.
>=20
> What am I missing?

That these counters are for stats. :)  You always have a race when reading =
the=20
amount, so you can choose what is "good enough" to satisfy the conflicting=
=20
requirements of "cheap" and "accurate".  To me, the cheapness of add+adc=20
(compared to say, a cmpxchg8b loop with a branch, etc.) is worth it if you=
=20
have this rare race.

=2D-=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607271058.13055.jhb>