From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 12:54:19 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 AA3AA16A4DE for ; Tue, 25 Jul 2006 12:54:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E15F743D4C for ; Tue, 25 Jul 2006 12:54:18 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dybkve@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6PCsBUb092738 for ; Tue, 25 Jul 2006 14:54:16 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6PCsBef092737; Tue, 25 Jul 2006 14:54:11 +0200 (CEST) (envelope-from olli) Date: Tue, 25 Jul 2006 14:54:11 +0200 (CEST) Message-Id: <200607251254.k6PCsBef092737@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <200607241712.23917.jhb@freebsd.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 25 Jul 2006 14:54:16 +0200 (CEST) X-Mailman-Approved-At: Tue, 25 Jul 2006 13:40:40 +0000 Cc: Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 12:54:19 -0000 John Baldwin wrote: > On Sunday 23 July 2006 20:03, Sten Daniel Sørsdal wrote: > > sthaug@nethelp.no wrote: > > > > > One approach that we could use for 64-bit counters would be to just > > > > > use 32-bits one, and poll them for overflow and bump an overflow > > > > > count. This assumes that the 32-bit counters overflow much less often > > > > > than the polling interval, and easily triples the amount of storage > > > > > for each of them... It is ugly :-( > > > > > > > > > What's wrong with the add+adc (asm) approach found on any i386? > > > > > > Presumably the fact that add + adc isn't an atomic operation. So if > > > you want to guarantee 64 bit consistency, you need locking or similar. > > > > > > > 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? > > I actually think that add + adc is ok for the case of incrementing simple > counters. You can even do 'inc ; addc $0' (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 ...) 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. What am I missing? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio