Date: Mon, 7 Jul 2003 13:45:12 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Chris Pressey <cpressey@catseye.mb.ca> Cc: stable@freebsd.org Subject: Re: Weird vmstat -s stats Message-ID: <20030707034511.GY430@gsmx07.alcatel.com.au> In-Reply-To: <20030706223206.09a17f29.cpressey@catseye.mb.ca> 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> <20030706215545.1c29c5ed.cpressey@catseye.mb.ca> <44u19zxcg4.fsf@be-well.ilk.org> <20030706223206.09a17f29.cpressey@catseye.mb.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-Jul-06 22:32:06 -0500, Chris Pressey <cpressey@catseye.mb.ca> wrote: >Still, it seems like there are two viable alternatives - > >1) use an atomically-updated 32-bit counter, which we know WILL >eventually yield an inaccurate result in a forseeable time frame; or >2) use a 64-bit counter of which only the bottom 32 bits are atomically >updated, which MAY yield an inaccurate result in the same time frame. In the second case, the top 32-bits also have to be atomically incremented for the result to be meaningful. Otherwise you will occasionally lose 2^32 units permanently. If there are two serial atomic updates you just occasionally lose 2^32 units temporarily. The third alternative is for applications that actually care about the result to simulate a 64-bit counter: If the 32-bit counter went backwards then the top 32-bits just incremented. This works as long as the counter can be sampled more than once between overflows. A fourth alternative is to wear the cost of 64-bit atomic operations on x86. The problem is that for the majority of users, the benefit doesn't justify the expected performance hit. >Even though it's not 100% guaranteed, the second option does strike me >as a small improvement over the first. Misleading 64-bit statistics (out by 2^32 occasionally) aren't necessarily an improvement on a 32-bit counter. To get an accurate result you still need the 'did the counter go backwards' test mentioned above. This has all been done to death in the past. If 64-bit counters are really critical to your application, I suggest you run up a patch that provides a compile-time option to switch between 32-bit and 64-bit counters. You might get enough support to get it committed as long as it is optional. Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030707034511.GY430>