Date: Mon, 24 Jul 2006 17:12:23 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Sten Daniel =?iso-8859-1?q?S=F8rsdal?= <lists@wm-access.no>, sthaug@nethelp.no Subject: Re: vmstat's entries type Message-ID: <200607241712.23917.jhb@freebsd.org> In-Reply-To: <44C40E66.8080805@wm-access.no> References: <200607191315.k6JDFpvM048354@lurza.secnetix.de> <20060723.205759.74723866.sthaug@nethelp.no> <44C40E66.8080805@wm-access.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 23 July 2006 20:03, Sten Daniel S=F8rsdal wrote: > 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 often > >>> 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 >=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? I actually think that add + adc is ok for the case of incrementing simple=20 counters. You can even do 'inc ; addc $0' =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607241712.23917.jhb>