From owner-freebsd-arch@FreeBSD.ORG  Sat Dec 19 14:56:43 2009
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 8D1A21065679;
	Sat, 19 Dec 2009 14:56:43 +0000 (UTC)
	(envelope-from Hartmut.Brandt@dlr.de)
Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32])
	by mx1.freebsd.org (Postfix) with ESMTP id 1CC1F8FC14;
	Sat, 19 Dec 2009 14:56:42 +0000 (UTC)
Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over
	TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); 
	Sat, 19 Dec 2009 15:56:40 +0100
Date: Sat, 19 Dec 2009 15:56:38 +0100 (CET)
From: Harti Brandt <hartmut.brandt@dlr.de>
X-X-Sender: brandt_h@beagle.kn.op.dlr.de
To: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net>
In-Reply-To: <20091219112711.GR55913@acme.spoerlein.net>
Message-ID: <20091219154206.E93919@beagle.kn.op.dlr.de>
References: <20091215103759.P97203@beagle.kn.op.dlr.de>
	<200912150812.35521.jhb@freebsd.org>
	<20091215183859.S53283@beagle.kn.op.dlr.de>
	<200912151313.28326.jhb@freebsd.org>
	<20091219112711.GR55913@acme.spoerlein.net>
X-OpenPGP-Key: harti@freebsd.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 19 Dec 2009 14:56:40.0372 (UTC)
	FILETIME=[78948740:01CA80BB]
Cc: freebsd-arch@freebsd.org
Subject: Re: network statistics in SMP
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Harti Brandt <harti@freebsd.org>
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Dec 2009 14:56:43 -0000

On Sat, 19 Dec 2009, Ulrich Sprlein wrote:

US>On Tue, 15.12.2009 at 13:13:28 -0500, John Baldwin wrote:
US>> On Tuesday 15 December 2009 12:45:13 pm Harti Brandt wrote:
US>> > I see. I was also thinking along these lines, but was not sure whether it 
US>> > is worth the trouble. I suppose this does not help to implement 64-bit 
US>> > counters on 32-bit architectures, though, because you cannot read them 
US>> > reliably without locking to sum them up, right?
US>> 
US>> Either that or you just accept that you have a small race since it is only stats. :)
US>
US>This might be stupid, but can we not easily *read* 64bit counters
US>on 32bit machines like this:
US>
US>do {
US>    h1 = read_upper_32bits;
US>    l1 = read_lower_32bits;
US>    h2 = read_upper_32bits;
US>    l2 = read_lower_32bits; /* not needed */
US>} while (h1 != h2);
US>
US>sum64 = (h1<<32) + l1;
US>
US>or something like that? If h2 does not change between readings, no
US>wrap-around has occured. If l1 was read in between the readings of h1
US>and h2, the code above is sound. Right?

I suppose this works only if it would be guaranteed that the CPU modifying 
the 64-bit value does this somehow faster than the CPU reading the data:

CPU1                    CPU2
----                    ----
write new h
			read h1 (new h)
			read l1 (old l)
			read h2 (new h)
write new l

It doesn't work too when the CPU first writes L and the H.

harti