Date: Thu, 03 Jan 2002 02:25:43 -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: <20020103102543.7737039EC@overcee.netplex.com.au> In-Reply-To: <200201030535.g035Zq062246@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :> 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 > > An ISA or PCI bus access is certainly expensive, but I don't see how > it applies to spl*() calls. The original spl*() implementation that we inherited caused every spl call to change the pic masks. BSDI only implemented lazy masking around BSD/OS 3.0 or so. I'm not sure exactly when bde's implementation went in (it may have got into 386bsd before the fork, or it may have been via the patchkit). We get away with simple assignment in RELENG_4 because we absolutely lock all reentrancy that can touch cpl etc with the giant mp_lock. All spl* calls are inside the giant kernel lock. Anyway, this is heading off on a tangent, but my point was the the objective of the original implementation (that we have a descendant of in RELENG_4) was to stop the spl* functions from hitting hardware, much more so than to minimize cli/sti usage. It just so happens that the implementation didn't need cli/sti very much. Places where those are used hasn't changed very much over time (ignoring the *horrible* things that were done when the APIC support was added). > The interrupt handler assembly has to > manipulate the controller no matter how spl*()'s are implemented > and that is where most of the optimizations were made (things like > AUTO_EOI and such). Since spl*() calls manipulate multiple interrupt > sources I don't think anyone would ever consider actually trying to > screw around with the PIC in spl*(), even if the PIC had been fast. It certainly used to. Many SYSV/386 commercial OS's used to up until (relatively) recently as well. This is going well off topic though. Incidently, probably 90%+ of freebsd boxes (all those that run GENERIC or similar) are essentially wire-oring the interrupt masks together due to the slip/ppp drivers in the kernel. On most of them, splanything() pretty much masks all interrupts. Check tty_imask, net_imask, and bio_imask and see for yourself (and check cambio/camnet as well). We *almost* have a boolean "interrupts on or off" state on most of these systems (not quite but almost). 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?20020103102543.7737039EC>