From owner-freebsd-current@FreeBSD.ORG Mon Jul 24 00:04:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12BBA16A4DD for ; Mon, 24 Jul 2006 00:04:22 +0000 (UTC) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76C7443D4C for ; Mon, 24 Jul 2006 00:04:21 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.6/8.13.6) with ESMTP id k6O04KPP030033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jul 2006 02:04:20 +0200 Message-ID: <44C40E66.8080805@wm-access.no> Date: Mon, 24 Jul 2006 02:03:50 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: 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> In-Reply-To: <20060723.205759.74723866.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 00:04:22 -0000 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