Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Jan 2002 16:13:00 -0800 (PST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Peter Jeremy <peter.jeremy@alcatel.com.au>, Michal Mertl <mime@traveller.cz>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, Bernd Walter <ticso@cicely8.cicely.de>, arch@FreeBSD.ORG
Subject:   Re: When to use atomic_ functions? (was: 64 bit counters)
Message-ID:  <XFMail.020102161300.jhb@FreeBSD.org>
In-Reply-To: <200201030002.g0302Eo60575@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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 <jhb@FreeBSD.org>  <><  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 
>                                       <dillon@backplane.com>

-- 

John Baldwin <jhb@FreeBSD.org>  <><  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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020102161300.jhb>