Date: Mon, 24 Jul 2006 02:03:50 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= <lists@wm-access.no> To: sthaug@nethelp.no Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type Message-ID: <44C40E66.8080805@wm-access.no> In-Reply-To: <20060723.205759.74723866.sthaug@nethelp.no> References: <200607191315.k6JDFpvM048354@lurza.secnetix.de> <20060720.093457.1661914908.imp@bsdimp.com> <44C3B674.3040804@wm-access.no> <20060723.205759.74723866.sthaug@nethelp.no>
next in thread | previous in thread | raw e-mail | index | archive | help
sthaug@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 ofte= n >>> 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? >=20 > 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. >=20 Would it not be necessary to do this locking anyway? I don't see how polling for overflow would help this consistency. Are both suggestions insufficient? --=20 Sten Daniel S=F8rsdal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44C40E66.8080805>