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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:58 UTC