Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Dec 2009 21:32:19 +0100
From:      Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net>
To:        Harti Brandt <hartmut.brandt@dlr.de>
Cc:        bde@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: network statistics in SMP
Message-ID:  <20091219203219.GS55913@acme.spoerlein.net>
In-Reply-To: <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> <20091219154206.E93919@beagle.kn.op.dlr.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091219203219.GS55913>