From owner-freebsd-current@FreeBSD.ORG  Mon Jul 24 21:28:55 2006
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 2451516A4E1
	for <freebsd-current@freebsd.org>; Mon, 24 Jul 2006 21:28:55 +0000 (UTC)
	(envelope-from jhb@freebsd.org)
Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net
	[66.23.211.162])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8F00243D45
	for <freebsd-current@freebsd.org>; Mon, 24 Jul 2006 21:28:54 +0000 (GMT)
	(envelope-from jhb@freebsd.org)
Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1])
	(authenticated bits=0)
	by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OLSpE8028792;
	Mon, 24 Jul 2006 17:28:52 -0400 (EDT) (envelope-from jhb@freebsd.org)
From: John Baldwin <jhb@freebsd.org>
To: freebsd-current@freebsd.org
Date: Mon, 24 Jul 2006 17:12:23 -0400
User-Agent: KMail/1.9.1
References: <200607191315.k6JDFpvM048354@lurza.secnetix.de>
	<20060723.205759.74723866.sthaug@nethelp.no>
	<44C40E66.8080805@wm-access.no>
In-Reply-To: <44C40E66.8080805@wm-access.no>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200607241712.23917.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by
	milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]);
	Mon, 24 Jul 2006 17:28:53 -0400 (EDT)
X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on
	server.baldwin.cx
X-Virus-Status: Clean
X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx
Cc: Sten Daniel =?iso-8859-1?q?S=F8rsdal?= <lists@wm-access.no>,
	sthaug@nethelp.no
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2006 21:28:55 -0000

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