vmstat's entries type

[Peter Jeremy]

On Thu, 2006-Jul-20 09:34:57 -0600, M. Warner Losh 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 :-(

You also need to provide helper functions to convert a {old count,
new count, overflow count} triplet into a 64-bit value for userland.

One area where this has benefits is per-CPU statistics: Each CPU
accumulates statistics in per-CPU space (so updates don't need atomic
operations).  The per-CPU statistics are then merged by the helper
functions as required (when referenced and often enough not to
overflow).  This approach reduces the cost of updating the raw
statistics at the cost of increasing the cost of accessing the
statistics - which is probably a worthwhile tradeoff for a counter
that it being incremented several thousand times a second but rarely
read (once per second would be unusually high).

The worst case would be rx/tx byte counters on high-speed NICs.  These
could incrememnt by 100e6/sec with gigabit (or 1e9/sec with 10gig).
The latter number means a polling interval of ~2 seconds (though 10gig
NICs are still rare).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20060720/7e62cde8/attachment.pgp