From owner-freebsd-arch Wed Jan 2 17: 9:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id E48A537B41A; Wed, 2 Jan 2002 17:09:22 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g0319Jd06655; Thu, 3 Jan 2002 02:09:20 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g0316Ctx046505; Thu, 3 Jan 2002 02:06:12 +0100 (CET)?g (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [10.1.7.11]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id g0316CW12934; Thu, 3 Jan 2002 02:06:12 +0100 (CET) Received: (from ticso@localhost) by cicely9.cicely.de (8.11.6/8.11.6) id g0316B562375; Thu, 3 Jan 2002 02:06:11 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Jan 2002 02:06:11 +0100 From: Bernd Walter To: Matthew Dillon Cc: John Baldwin , Peter Jeremy , Michal Mertl , Bruce Evans , Mike Smith , Bernd Walter , arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <20020103010611.GD53199@cicely9.cicely.de> References: <200201030024.g030Oip60860@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201030024.g030Oip60860@apollo.backplane.com> User-Agent: Mutt/1.3.24i X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 02, 2002 at 04:24:44PM -0800, Matthew Dillon wrote: > :Note that critical sections don't impose locking, right now they just disable > :interrupts on the local CPU. Eventually they will also prevent preemptions for > :any setrunqueue's done inside a critical section and defer the switches until > :the critical section is exited. If you pin processes/threads to CPU's when > :they get interrupted so they resume on the same CPU and only migrate at > :setrunqueue(), then you still might need to disable interrupts if your update > :of a per-CPU variable isn't atomic since when you return to the thread, it > :might do a modify-write of a stale variable. Think of an interrupt handler > :being interrupted by another interrupt. Thus, I think it would still be wise > :to disable interrupts for per-CPU stuff. At least, for ones that can be > :modified by interrupt handlers. Also, per-thread counters don't need locking. > > But if it is protected by a mutex, and an interrupt occurs while you > hold the mutex, the interrupt thread will not be able to run (or > at least will wind up blocking while getting the mutex) until you release > your mutex, at which point your modifications have been synchronized out > (releasing the mutex ensures this). > > The critical section stuff would be more palettable if it weren't so > expensive. Couldn't we just have a per-cpu critical section count > and defer the interrupt? (e.g. like the deferred mechanism we used for > spl()s). Then we would have an incredibly cheap mechanism for accessing > per-cpu caches (like per-cpu mbuf freelists, for example) which could > further be adapted for use by zalloc[i]() and malloc(). > > I am really beginning to hate not being able to depend on anything > without having to make expensive calls first. sti and cli are very > expensive instructions. > > (We are really talking about two different ways to increment a counter > here... one way using a mutex for protection, the other way using a > critical section and per-cpu space). A mutex includes atomic_acq/rel calls which not only are atomic_ but also require memory barriers, because they protect unnamed space. Using a mutex for accessing 2 or maybe up to 3 values doesn't bring you anything compared to using atomic_ access directly. critical sections doesn't do better. Using atomic_ functions and per CPU counters still sounds best to me unless there are many of them updated in row. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message