From owner-freebsd-arch@FreeBSD.ORG Sat Dec 19 21:09:11 2009 Return-Path: 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 CD80C106566B; Sat, 19 Dec 2009 21:09:11 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [217.20.127.186]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3128FC1C; Sat, 19 Dec 2009 21:09:10 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id nBJKWJPT057539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Dec 2009 21:32:19 +0100 (CET) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id nBJKWJYV057538; Sat, 19 Dec 2009 21:32:19 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sat, 19 Dec 2009 21:32:19 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Harti Brandt Message-ID: <20091219203219.GS55913@acme.spoerlein.net> Mail-Followup-To: Harti Brandt , freebsd-arch@freebsd.org, bde@freebsd.org 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> <20091219154206.E93919@beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091219154206.E93919@beagle.kn.op.dlr.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: bde@freebsd.org, freebsd-arch@freebsd.org Subject: Re: network statistics in SMP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 21:09:11 -0000 On Sat, 19.12.2009 at 15:56:38 +0100, Harti Brandt wrote: > On Sat, 19 Dec 2009, Ulrich Sprlein wrote: > > >On Tue, 15.12.2009 at 13:13:28 -0500, John Baldwin wrote: > >> On Tuesday 15 December 2009 12:45:13 pm Harti Brandt wrote: > >> > I see. I was also thinking along these lines, but was not sure whether it > >> > is worth the trouble. I suppose this does not help to implement 64-bit > >> > counters on 32-bit architectures, though, because you cannot read them > >> > reliably without locking to sum them up, right? > >> > >> Either that or you just accept that you have a small race since it is only stats. :) > > > >This might be stupid, but can we not easily *read* 64bit counters > >on 32bit machines like this: > > > >do { > > h1 = read_upper_32bits; > > l1 = read_lower_32bits; > > h2 = read_upper_32bits; > > l2 = read_lower_32bits; /* not needed */ > >} while (h1 != h2); > > > >sum64 = (h1<<32) + l1; > > > >or something like that? If h2 does not change between readings, no > >wrap-around has occured. If l1 was read in between the readings of h1 > >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. To be honest, I didn't even think about the 64 bit writes being non-atomic, too. So, of course my suggestion was way too naive. Also thanks to Bruce for re-iterating the whole write/read ordering stuff yet again. :) Regards, Uli