From owner-freebsd-current@FreeBSD.ORG  Fri Jul 28 12:15:31 2006
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 B38BE16A4DE;
	Fri, 28 Jul 2006 12:15:31 +0000 (UTC)
	(envelope-from b.candler@pobox.com)
Received: from rune.pobox.com (rune.pobox.com [208.210.124.79])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3CAE043D45;
	Fri, 28 Jul 2006 12:15:31 +0000 (GMT)
	(envelope-from b.candler@pobox.com)
Received: from rune (localhost [127.0.0.1])
	by rune.pobox.com (Postfix) with ESMTP id 4B1587B63F;
	Fri, 28 Jul 2006 08:15:52 -0400 (EDT)
Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com
	[212.74.113.67])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id D6F8179B61;
	Fri, 28 Jul 2006 08:15:49 -0400 (EDT)
Received: from lists by mappit.local.linnet.org with local (Exim 4.61
	(FreeBSD)) (envelope-from <b.candler@pobox.com>)
	id 1G6RFW-000Bh4-0p; Fri, 28 Jul 2006 13:15:26 +0100
Date: Fri, 28 Jul 2006 13:15:25 +0100
From: Brian Candler <B.Candler@pobox.com>
To: John Baldwin <jhb@freebsd.org>
Message-ID: <20060728121525.GA44917@uk.tiscali.com>
References: <200607251254.k6PCsBef092737@lurza.secnetix.de>
	<200607271058.13055.jhb@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200607271058.13055.jhb@freebsd.org>
User-Agent: Mutt/1.4.2.1i
Cc: freebsd-current@freebsd.org, Oliver Fromme <olli@lurza.secnetix.de>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jul 2006 12:15:31 -0000

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.