From owner-freebsd-arch@FreeBSD.ORG Sun Aug 19 04:53:57 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F84C16A419; Sun, 19 Aug 2007 04:53:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2D46C13C428; Sun, 19 Aug 2007 04:53:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l7J4rrwo029490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Aug 2007 14:53:55 +1000 Date: Sun, 19 Aug 2007 14:53:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Pawel Jakub Dawidek In-Reply-To: <20070818220756.GH6498@garage.freebsd.pl> Message-ID: <20070819142214.O34036@delplex.bde.org> References: <20070818120056.GA6498@garage.freebsd.pl> <20070818220756.GH6498@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: Lockless uidinfo. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2007 04:53:57 -0000 On Sun, 19 Aug 2007, Pawel Jakub Dawidek wrote: > Two more things... > >> The patch below remove per-uidinfo locks: >> >> http://people.freebsd.org/~pjd/patches/uidinfo_lockless.patch > > We could upgrade from lock-free algorithm I used here to wait-free > algorithm, but we don't have atomic_fetchadd_long(). How hard will it be > to implement it? > > We could then change: > > do { > old = uip->ui_proccnt; > if (old + diff > max) > return (0); > } while (atomic_cmpset_long(&uip->ui_proccnt, old, old + diff) == 0); > > to something like this: > > if (atomic_fetchadd_long(&uip->ui_proccnt, diff) + diff > max) { > atomic_subtract_long(&uip->ui_proccnt, diff); > return (0); > } atomic_*long() shouldn't exist (and doesn't exist in my version) since longs should actually be long (twice as long as registers) and thus especially epensive to lock. long is just a bogus historical type for ui_proccnt (in case int is 16 bits, and the null set of old systems with 16-bit ints have non-old CPU resources for >= 65536 processes per user). There are several variables like this. This causes problems spelling atomic accesses to such variables. Sometimes on 64-bit machines, asking for a long (128 bits) is actually useful for the bogus reason that long has the wrong size (64 bits) and 64-bits is actually useful on 64-bit machines though not needed on 32-bit machines. >> I needed to change ui_sbsize from rlim_t (64bit) to long, because we >> don't have 64bit atomics on all archs, and because sbsize represents >> size in bytes, it can't go beyond 32bit on 32bit archs (PAE might be a >> bit of a problem). This problem is similar. rlim_t is 64 bits since 64 bits is needed for a few limits and 128 bits isn't needed yet, so the same type is used for all limits. This causes problems locking it even on 64-bit machines where longs have the wrong size (not 2*64), since although 64-bit machines have 64-bit atomics, there is no good way to spell the atomic accesses to an rlim_t. On 32-bit machines, there is no way at all to spell the atomic accesses to an rlim_t. Here the spelling problems prevent misuse of atomics on longs. Otherwise, the type for a size should be something like vm_size_t, and then the problem is the spelling of atomic accesses to vm_size_t's. This problem is handled for pointers by type-punning pointers to ints or longs in . (The amd64 atomic.h uses longs. It should use int64_t or register_t. It uses 8-bit DOS/Windowspeak "Operations on 32-bit double words" and "Operations on 64-bit quad words" in comments copied from the i386 version. On 64-bit machines, 32 bits is half a word, not a double word...) Bruce