From owner-freebsd-current@FreeBSD.ORG Sat Jul 29 22:32:38 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 DB04A16A4DD for ; Sat, 29 Jul 2006 22:32:38 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4175D43D53 for ; Sat, 29 Jul 2006 22:32:37 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6TMWZf3064985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 30 Jul 2006 00:32:36 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Brian Candler In-Reply-To: <20060729211530.GA50342@uk.tiscali.com> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-2 Date: Sun, 30 Jul 2006 00:32:20 +0200 Message-Id: <1154212340.3609.18.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Peter Jeremy , freebsd-current@freebsd.org 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: Sat, 29 Jul 2006 22:32:38 -0000 Brian Candler píše v so 29. 07. 2006 v 22:15 +0100: > On Sun, Jul 30, 2006 at 06:56:55AM +1000, Peter Jeremy wrote: > > On Sat, 2006-Jul-29 18:13:32 +0200, Michal Mertl wrote: > > >#define PCPU_LAZY_INC(var) (++*PCPU_PTR(var)) > > > > I missed that. > > > > >and function vcnt from sys/vm/vm_meter.c > > > > vcnt() accumulates multiple 32-bit counters into a 32-bit result. Getting > > a 64-bit result means additionally tracking overflows in each counter. > > But if you have per-CPU counters, there's no problem with accumulating > 64-bit values in the first place. No. AFAIK the fact that the data is per-CPU does not guarantee that much. If the operation is not atomic you can not really believe in anything. That is the reason why the macro is called LAZY. As multiple people already stated, there is no ideal solution. Either the counting is cheap or it is correct. The comment in src/sys/pcpu.h says: /* * MI PCPU support functions * * PCPU_LAZY_INC() - Lazily increment a per-cpu stats counter, without * guarenteeing atomicity or even necessarily consistency. * * XXX we need to create MD primitives to support * this to guarentee at least some level of consistency, * i.e., to prevent us from totally corrupting the * counters due to preemption in a multi-instruction * increment sequence for architectures that do not * support single-instruction memory increments. */ Michal