From owner-freebsd-stable@FreeBSD.ORG Sun Jul 6 20:46:21 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 851DB37B401 for ; Sun, 6 Jul 2003 20:46:21 -0700 (PDT) Received: from alcanet.com.au (mail2.alcanet.com.au [203.62.196.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1130D43F85 for ; Sun, 6 Jul 2003 20:46:20 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp01.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1])h673jVxC001231; Mon, 7 Jul 2003 13:45:37 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp01.alcatel.com.au (Lotus Domino Release 5.0.12) with ESMTP id 2003070713423550:177774 ; Mon, 7 Jul 2003 13:42:35 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.9/8.12.9) with ESMTP id h673jC7d002486; Mon, 7 Jul 2003 13:45:12 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.9/8.12.9/Submit) id h673jC0e002485; Mon, 7 Jul 2003 13:45:12 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Mon, 7 Jul 2003 13:45:12 +1000 From: Peter Jeremy To: Chris Pressey Message-ID: <20030707034511.GY430@gsmx07.alcatel.com.au> Mail-Followup-To: Chris Pressey , stable@freebsd.org 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> Mime-Version: 1.0 In-Reply-To: <20030706223206.09a17f29.cpressey@catseye.mb.ca> User-Agent: Mutt/1.4.1i X-MIMETrack: Itemize by SMTP Server on SYDSMTP01/AlcatelAustralia(Release 5.0.12 |February 13, 2003) at 07/07/2003 01:42:35 PM,|February 13, 2003) at 07/07/2003 01:43:00 PM, Serialize complete at 07/07/2003 01:43:00 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline cc: stable@freebsd.org Subject: Re: Weird vmstat -s stats X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2003 03:46:21 -0000 On 2003-Jul-06 22:32:06 -0500, Chris Pressey 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