Weird vmstat -s stats

[Peter Jeremy]

On 2003-Jul-06 22:32:06 -0500, Chris Pressey <cpressey at catseye.mb.ca> wrote:
>Still, it seems like there are two viable alternatives -
>
>1) use an atomically-updated 32-bit counter, which we know WILL
>eventually yield an inaccurate result in a forseeable time frame; or
>2) use a 64-bit counter of which only the bottom 32 bits are atomically
>updated, which MAY yield an inaccurate result in the same time frame.

In the second case, the top 32-bits also have to be atomically
incremented for the result to be meaningful.  Otherwise you will
occasionally lose 2^32 units permanently.  If there are two serial
atomic updates you just occasionally lose 2^32 units temporarily.

The third alternative is for applications that actually care about
the result to simulate a 64-bit counter:  If the 32-bit counter
went backwards then the top 32-bits just incremented.  This works
as long as the counter can be sampled more than once between overflows.

A fourth alternative is to wear the cost of 64-bit atomic operations
on x86.  The problem is that for the majority of users, the benefit
doesn't justify the expected performance hit.

>Even though it's not 100% guaranteed, the second option does strike me
>as a small improvement over the first.

Misleading 64-bit statistics (out by 2^32 occasionally) aren't
necessarily an improvement on a 32-bit counter.  To get an accurate
result you still need the 'did the counter go backwards' test
mentioned above.

This has all been done to death in the past.  If 64-bit counters are
really critical to your application, I suggest you run up a patch that
provides a compile-time option to switch between 32-bit and 64-bit
counters.  You might get enough support to get it committed as long
as it is optional.

Peter