From owner-freebsd-arch Wed Jan 2 16:13:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 4352437B420 for ; Wed, 2 Jan 2002 16:13:14 -0800 (PST) Received: (qmail 3785 invoked from network); 3 Jan 2002 00:13:13 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Jan 2002 00:13:13 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200201030002.g0302Eo60575@apollo.backplane.com> Date: Wed, 02 Jan 2002 16:13:00 -0800 (PST) From: John Baldwin To: Matthew Dillon Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Cc: Peter Jeremy , Michal Mertl , Bruce Evans , Mike Smith , Bernd Walter , arch@FreeBSD.ORG 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 03-Jan-02 Matthew Dillon wrote: >:Look at PCPU_GET/PCPU_SET. Note that since an interrupt can preempt you and >:push you off onto another CPU, you have to use a critical section while >:updating per-CPU variables. If desired, some kind of free area could be >:stuck >:in struct pcpu (or more likely, struct pcpu would hold a pointer to the area) >:that could be galloc/gfree'd or some such. >: >:-- >: >:John Baldwin <>< http://www.FreeBSD.org/~jhb/ >:"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > Maybe we are going about this all wrong. If a particular interface > counter can only be modified from the device interrupt, or only be > modified while holding the appropriate mutex, do we need any locking > at all? 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. > -Matt > Matthew Dillon > -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message