From owner-freebsd-arch@FreeBSD.ORG Mon May 21 12:07:10 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E05E16A421 for ; Mon, 21 May 2007 12:07:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE8013C484 for ; Mon, 21 May 2007 12:07:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so903896ugh for ; Mon, 21 May 2007 05:07:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=EMzzKCPlzpVTPb9zZWHa+w/ksIlo5oGu1SEa386G9j4jFnp72ipPsGElQwil/ZyVxCehGKkqt91W5deUsXjMXv6Y1/sLujvsM3NY0ejRMGbzHjic5nwoII25ji82LUch9czPmk7Ozj4Uh/91VoAwbHs4dT+UCZ9qb/fBWIthe8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=Sgeuq6gwmZEGfIah6nBp0q6Rw7qop1z1e+cZBv+3Ur8HlF+X1AMSX964qx7DrRTazgvUuc7DpWmff6efOuyqUM1IpH6tR9HSYE+/pAgUP/Tj9yl6CbJZxjDvCV5cpbZNkO8+Vk7hwCRG12asoPELtKQGh6EVAxVCML/Mzco+j6U= Received: by 10.82.113.6 with SMTP id l6mr8501805buc.1179749228355; Mon, 21 May 2007 05:07:08 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTP id c25sm9977624ika.2007.05.21.05.07.06; Mon, 21 May 2007 05:07:07 -0700 (PDT) Message-ID: <4651FCB5.7070604@FreeBSD.org> Date: Mon, 21 May 2007 22:10:29 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Bruce Evans References: <20070520155103.K632@10.0.0.1> <20070521113648.F86217@besplex.bde.org> <20070520213132.K632@10.0.0.1> <4651CAB8.8070007@FreeBSD.org> <4651CE2F.8080908@FreeBSD.org> <20070521022847.D679@10.0.0.1> <20070521195811.G56785@delplex.bde.org> In-Reply-To: <20070521195811.G56785@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: arch@FreeBSD.org Subject: Re: sched_lock && thread_lock() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2007 12:07:10 -0000 Bruce Evans wrote: > On Mon, 21 May 2007, Jeff Roberson wrote: > > > The function that I described is only linked to vm paging. Statistics are > vital for vm paging, though perfectly up to date statistics might not be. Exactly, this is what I meant too. > Also, atomic ops don't help much for VMCNT_GET() and VMCNT_SET(): > VMCNT_GET(): atomic ops are not used. If they were used, then they would > just reduce race windows, since without a lock the data may change > immediately after you read it, whether or not you read it atomically. > Atomic ops are still strictly needed to give atomic accesses to > variables that cannot naturally be accessed atomically (perhaps because > they are wider than the bus width), but everything in struct vmmeter > is u_int so this is only a problem on exotic hardware. > VMCNT_SET(): atomic ops are used. This doesn't help, since with multiple > writers, without locks there would be races deciding what to write > (starting from unlocked values) and then races writing. I think this > isn't a problem because VMCNT_SET() is only used in initialization code > when only one thread is running. I think your objection about VMCNT_SET() is pretty right, it should not use atomic_* since it is used just for initializations. We can probabilly change it in short times. And as you stated, assuming reads to be atomic is not a problem here since we use volatile and all vmmeter fields are on machine natural boundaries. > We already have inconsistent accesses via PCPU_LAZY_INC(), and I think > all cases where you don't really care about the values can be handled > better by PCPU_LAZY_INC(). (Though I don't like PCPU_LAZY_INC(), since > it gives namespace pollution, a larger race window while combining the > values, complications, and missing support for combining the values > in dead kernels.) Cases that can be handled by PCPU_LAZY_INC() are > distinguished by the variables being monotonically increasing with > time (until wrapping at UINT_MAX breaks them) and nothing except > userland looking at them. The userland accesses are full of races, > but userland doesn't really care. If accessing the pcpu is inefficient, > then PCPU_LAZY_INC() can always use atomic ops if that is less inefficient. Yes, but how do you manage to mantain per-cpu datas and not using per-cpu fields? Do you want it fitting a table? In this case probabilly you will need an extra-lock for the table that will increases overhead. Thanks, Attilio