Re: vmstat's entries type

Sten Daniel Sørsdal <lists_at_wm-access.no> 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.

When using the polling solution, the overhead of checking
for atomicity is moved to the "client" side, so no locking
is necessary.  The idea is that most counters are updated
much more often than they're read, so the updating code
should be as efficient as possible, at the cost of more
overhead in the reading code.

For example, the code reading the sysctl has to perform
the following actions (pseudo code):

1. OV1 = read overflow counter
2. OLD = read old counter value
3. NEW = read new counter value
4. OV2 = read overflow counter
5. if OV2 != OV1: go back to 1.
6. if OLD > NEW: OV1++
7. return OV1 * 2^32 + NEW

I think that should cover all possible race conditions.
The code updating the overflow counter at certain polling
intervals would have to do something similar, of course.

The main advantage of that approach is the fact that the
counter updating code is a simple 32bit "add".  There's
no locking or anything required, i.e. it's most efficient,
which is important if the counter is updated very often,
like vm.stats.sys.v_swtch or vm.stats.sys.v_syscall or
vm.stats.sys.v_intr.

The disadvantage is that polling the counters for overflows
is somewhat ugly, in terms of design.  However, personally
I think that it's an acceptable solution, given the fact
that it is only required for 32bit "legacy" hardware.
64bit machines will be more and more common and become the
"standard", and they don't need such work-arounds for 64bit
counters.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"C++ is over-complicated nonsense. And Bjorn Shoestrap's book
a danger to public health. I tried reading it once, I was in
recovery for months."
        -- Cliff Sarginson