Date: Sun, 30 Jul 2006 00:32:20 +0200 From: Michal Mertl <mime@traveller.cz> To: Brian Candler <B.Candler@pobox.com> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-current@freebsd.org Subject: Re: vmstat's entries type Message-ID: <1154212340.3609.18.camel@genius.i.cz> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1154212340.3609.18.camel>