vmstat's entries type
John Baldwin
jhb at freebsd.org
Thu Jul 27 15:06:23 UTC 2006
On Tuesday 25 July 2006 08:54, Oliver Fromme wrote:
> John Baldwin <jhb at freebsd.org> wrote:
> > On Sunday 23 July 2006 20:03, Sten Daniel Sørsdal wrote:
> > > sthaug at nethelp.no wrote:
> > > > > > One approach that we could use for 64-bit counters would be to
just
> > > > > > use 32-bits one, and poll them for overflow and bump an overflow
> > > > > > count. This assumes that the 32-bit counters overflow much less
often
> > > > > > than the polling interval, and easily triples the amount of
storage
> > > > > > for each of them... It is ugly :-(
> > > > > >
> > > > > What's wrong with the add+adc (asm) approach found on any i386?
> > > >
> > > > Presumably the fact that add + adc isn't an atomic operation. So if
> > > > you want to guarantee 64 bit consistency, you need locking or
similar.
> > > >
> > >
> > > 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?
> >
> > I actually think that add + adc is ok for the case of incrementing simple
> > counters. You can even do 'inc ; addc $0'
>
> (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 ...)
>
> 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.
>
> What am I missing?
That these counters are for stats. :) You always have a race when reading the
amount, so you can choose what is "good enough" to satisfy the conflicting
requirements of "cheap" and "accurate". To me, the cheapness of add+adc
(compared to say, a cmpxchg8b loop with a branch, etc.) is worth it if you
have this rare race.
--
John Baldwin
More information about the freebsd-current
mailing list