From owner-freebsd-current@FreeBSD.ORG Thu Jul 20 15:35:36 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 B559116A4E2 for ; Thu, 20 Jul 2006 15:35:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E589343D55 for ; Thu, 20 Jul 2006 15:35:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6KFYeHA057040; Thu, 20 Jul 2006 09:34:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 20 Jul 2006 09:34:57 -0600 (MDT) Message-Id: <20060720.093457.1661914908.imp@bsdimp.com> To: freebsd-current@freebsd.org, olli@lurza.secnetix.de From: "M. Warner Losh" In-Reply-To: <200607191315.k6JDFpvM048354@lurza.secnetix.de> References: <1153312635.1261.22.camel@genius.i.cz> <200607191315.k6JDFpvM048354@lurza.secnetix.de> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 20 Jul 2006 09:34:40 -0600 (MDT) Cc: 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, 20 Jul 2006 15:35:36 -0000 In message: <200607191315.k6JDFpvM048354@lurza.secnetix.de> Oliver Fromme writes: : Michal Mertl wrote: : > We had discussions about 64 bit counters several times during the years : > (I made a huge patch which turned every network related counter 64bit : > and all accesses were made with a macro) and the conclusion was that it : > isn't worth it. : > : > 64bit numbers are too expensive to do correctly on 32bit machines. When : > done incorrectly they can easily get incorrect and that is probably : > worse than a simple counter in machine's native word size (which can : > still get incorrect on some architectures). : > : > I expect you know that long is usually 64bit wide on 64bit : > architectures. The discussion about 64bit counters on 32bit machines : > doesn't make much sense when AMD64 is becoming the mainstream : > architecture and the right type to use for integers (that can get : > "large") is long IMHO. : : I see. I'm mostly a userland programmer, and when there's : a variable that might overflow 32 bits, then I always use a : 64 bit type (e.g. uint64_t), no matter whether I'm on a 32 : bit or 64 bit architecture. It's all about portability and : reliability. In fact, I rarely use "long", because I think : it's not very useful. : : However, I got your point. Kernel programming is different : from userland programming, and I'm aware that using 64 bit : values can cause problems on 32 bit architectures (which I : mentioned in my previous mail). 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 :-( Warner