Date: Fri, 28 Jul 2006 13:15:25 +0100 From: Brian Candler <B.Candler@pobox.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Oliver Fromme <olli@lurza.secnetix.de> Subject: Re: vmstat's entries type Message-ID: <20060728121525.GA44917@uk.tiscali.com> In-Reply-To: <200607271058.13055.jhb@freebsd.org> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 27, 2006 at 10:58:12AM -0400, John Baldwin wrote: > That these counters are for stats. :) You always have a race when reading the > amount, so you can choose what is "good enough" to satisfy the conflicting > requirements of "cheap" and "accurate". To me, the cheapness of add+adc > (compared to say, a cmpxchg8b loop with a branch, etc.) is worth it if you > have this rare race. You can work around the problem when reading - e.g. read twice and check the values are close. But is add + adc safe for update? What about the following: - processor 1 reads low32 as FFFFFFFF - processor 2 reads low32 as FFFFFFFF - processor 1 writes low32 as 00000000 and sets carry - processor 2 writes low32 as 00000000 and sets carry - processor 1 adds 1 to high32 - processor 2 adds 1 to high32 I'm not saying this sequence can definitely occur - I'm thinking from a general point of view, and I don't know the i386 instruction set. It just seems plausible. OTOH, if the above race can occur, it would imply that even a simple 32-bit counter update could lose counts. Regards, Brian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060728121525.GA44917>