From owner-freebsd-current@FreeBSD.ORG Thu Jul 27 15:06:22 2006 Return-Path: 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 EBBF516A4DE for ; Thu, 27 Jul 2006 15:06:22 +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 AA69F43D49 for ; Thu, 27 Jul 2006 15:06:21 +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 k6RF6H4t077661; Thu, 27 Jul 2006 11:06:17 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 27 Jul 2006 10:58:12 -0400 User-Agent: KMail/1.9.1 References: <200607251254.k6PCsBef092737@lurza.secnetix.de> In-Reply-To: <200607251254.k6PCsBef092737@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200607271058.13055.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]); Thu, 27 Jul 2006 11:06:17 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1623/Wed Jul 26 18:35:11 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: Oliver Fromme 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:06:23 -0000 On Tuesday 25 July 2006 08:54, Oliver Fromme wrote: > John Baldwin wrote: > > 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= =20 just > > > > > > use 32-bits one, and poll them for overflow and bump an overfl= ow > > > > > > count. This assumes that the 32-bit counters overflow much le= ss=20 often > > > > > > than the polling interval, and easily triples the amount of=20 storage > > > > > > for each of them... It is ugly :-( > > > > > >=20 > > > > > 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=20 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? > >=20 > > I actually think that add + adc is ok for the case of incrementing sim= ple=20 > > counters. You can even do 'inc ; addc $0' >=20 > (I'm familiar with asm programming, but I'm not a low-level > threading or SMP expert, so please excuse me if this is a > dumb question ...) >=20 > If you just do add+adc (or inc+adc) and another thread (on > the same or different processor, I don't know) happens to > read the counter value at the same time (i.e. after the > lower 32bit have overflowed, but before the upper 32bit get > incremented), then that other thread would get a value > that's off by 2^32. >=20 > What am I missing? That these counters are for stats. :) You always have a race when reading = the=20 amount, so you can choose what is "good enough" to satisfy the conflicting= =20 requirements of "cheap" and "accurate". To me, the cheapness of add+adc=20 (compared to say, a cmpxchg8b loop with a branch, etc.) is worth it if you= =20 have this rare race. =2D-=20 John Baldwin