Date: Fri, 21 Jul 2006 05:28:10 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-current@freebsd.org, olli@lurza.secnetix.de Subject: Re: vmstat's entries type Message-ID: <20060720192810.GD716@turion.vk2pj.dyndns.org> In-Reply-To: <20060720.093457.1661914908.imp@bsdimp.com> References: <1153312635.1261.22.camel@genius.i.cz> <200607191315.k6JDFpvM048354@lurza.secnetix.de> <20060720.093457.1661914908.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--5p8PegU4iirBW1oA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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).
--=20
Peter Jeremy
--5p8PegU4iirBW1oA
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)
iD8DBQFEv9lI/opHv/APuIcRAiIpAJ4uMZxOWLAPv9XgbCqQksvUaFjbcQCfYyS9
8+Sb+N1TJrRyaTktRoMyL9w=
=IoYL
-----END PGP SIGNATURE-----
--5p8PegU4iirBW1oA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060720192810.GD716>