Date: Sat, 19 Dec 2009 15:56:38 +0100 (CET) From: Harti Brandt <hartmut.brandt@dlr.de> To: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net> Cc: freebsd-arch@freebsd.org Subject: Re: network statistics in SMP Message-ID: <20091219154206.E93919@beagle.kn.op.dlr.de> In-Reply-To: <20091219112711.GR55913@acme.spoerlein.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091219154206.E93919>