Date: Sun, 06 Jul 2003 21:55:45 -0500 From: Chris Pressey <cpressey@catseye.mb.ca> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: freebsd-stable@freebsd.org Subject: Re: Weird vmstat -s stats Message-ID: <20030706215545.1c29c5ed.cpressey@catseye.mb.ca> In-Reply-To: <20030706213540.GU430@gsmx07.alcatel.com.au> References: <200307051728.24681.me@farid-hajji.de> <44brw8g26e.fsf@be-well.ilk.org> <200307060029.00866.me@farid-hajji.de> <3F07576F.4030105@mac.com> <20030706213540.GU430@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jul 2003 07:35:40 +1000 Peter Jeremy <peter.jeremy@alcatel.com.au> wrote: > On 2003-Jul-05 18:55:43 -0400, Chuck Swiger <cswiger@mac.com> wrote: > >Farid Hajji wrote: > >[ ... ] > >>Shouldn't such counters be at least 64 bit wide? > > > >You betcha. :-) The problem is that a 32-bit CPU, like the Intel > >x86 family, can't increment a 64-bit counter atomicly. > > This isn't absolutely true. You _can_ perform atomic 64-bit > operations on an x86 (for x>=5), they are just extremely expensive. > > There are regular threads on this sort of problem and I don't believe > anyone has come up with a solution that did not involve overheads that > were considered unacceptable in the general case. > > Peter 'Scuse me if I'm out of my depth here, but wouldn't the atomic 64-bit update only have to be done when the lower 32 bits were about to wrap (which would be relatively infrequent)? The check to see if the lower 32 bits were about to wrap would be relatively cheap, too, I'd think. That's just an idle guess, though. -Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030706215545.1c29c5ed.cpressey>