Date: Wed, 02 Jan 2002 20:58:49 -0800 From: Peter Wemm <peter@wemm.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, Bernd Walter <ticso@cicely8.cicely.de>, Mike Smith <msmith@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Michal Mertl <mime@traveller.cz>, Peter Jeremy <peter.jeremy@alcatel.com.au> Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <20020103045849.5B53039EC@overcee.netplex.com.au> In-Reply-To: <200201030112.g031CnN61108@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> :> expensive. Couldn't we just have a per-cpu critical section count
> :> and defer the interrupt? (e.g. like the deferred mechanism we used fo
r
> :> spl()s). Then we would have an incredibly cheap mechanism for accessi
ng
> :> per-cpu caches (like per-cpu mbuf freelists, for example) which could
> :> further be adapted for use by zalloc[i]() and malloc().
> :
> :Err, it does maintain a count right now and only does the actual change of
> :interrupt state when entering and exiting critical sections at the top-level
.
> :sti and cli aren't very expensive though. Critical sections are more expens
ive
> :on other archs though. For example, it's a PAL call on alpha. Although, sp
l's
> :were PAL calls on alpha as well. On ia64 it's a single instruction but one
that
> :requires a stop.
>
> Most of the critical section code in the system is going to be at
> the top level. sti and cli *ARE* expensive, that's why the original
> spl code went to such great lengths to avoid calling them. I
> believe one or both instructions synchronizes the cpu pipeline,
> interrupting instruction flow. It is nasty stuff.
Not quite.. We went to extremes to avoid touching the ISA PIC, since that
meant going over the 4.77Mhz (or 8Mhz) isa bus.. potentially taking many
hundreds of cpu clock ticks per inb/outb. cli/sti is nothing compared to
that. The spl code optimized the mask updates on the PIC, not cli/sti
as such. The APIC is worse since it could take 40+ IO operations to set
the complete mask, although thankfully at FSB speeds (not
cpu core speed), not ISA speed.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?20020103045849.5B53039EC>