Date: Thu, 1 May 2003 17:41:54 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr Message-ID: <20030501164354.S18480@gamplex.bde.org> In-Reply-To: <20030430.095215.48529965.imp@bsdimp.com> References: <16047.59842.60959.352839@grasshopper.cs.duke.edu> <20030430.095215.48529965.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Apr 2003, M. Warner Losh wrote: > In message: <12432.1051717236@critter.freebsd.dk> > "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes: > : In message <16047.59842.60959.352839@grasshopper.cs.duke.edu>, Andrew Gallatin > : writes: > : > > : >Poul-Henning Kamp writes: > : > > In message <16047.59314.532227.475952@grasshopper.cs.duke.edu>, Andrew Gallatin > : > > writes: > : > > >Dumb question: Exactly what is one allowed to do in an INTR_FAST > : > > >interrupt context? Obviously, you can't sleep. But can you call > : > > >wakeup()? > : > > > : > > Calling wakeup() is just about it, but we should actually define it > : > > more precisely in a suitable man-page. I would have thought that it was obviously unsafe. It is like signal handling, but more so (the restrictions for signal handlers are more like those for ordinary interrupt handlers). Only a very limited set of functions may be called from signal handlers, and putting the list in a man page does very little to prevent ones not in the list being called. No INTR_FAST handlers in -current except loran and adlink seem to actually call wakeup(), but these drivers are just bad examples. The don't even use mutexes. > : >That would be cool. Since wakeup() uses a spinlock, I assume that > : >spinlocks are generally OK too.. > : > : I'm not sure you should infer too much yet... > > Yes. A spinlock in the context of wakeup being safe might be > radically different than spinlocks generally being safe. > > I'm not sure that wakeup is safe in a fast interrupt context even. > I've always had to create a soft interrupt and call the sched routine > to get it to run. The situation in -current seems to be similar to the one for the one for malloc() that started this thread(). Calling wakeup() from your INTR_FAST handler may be safe enough for you, since wakeup() spins on sched_lock as necessary and your driver may not care about this (though it shouldn't use a INTR_FAST handler if it doesn't care about efficiency. However, this increases latency and may affect overheads (+-) for other parts of the system. E.g., in the !SMP case, wakeup() won't spin on sched_lock, since sched_lock cannot be held at that point else we would have deadlock, so the direct cost is tiny. The cost is indirect: to prevent sched_lock being held, holding sched_lock (actually any spinlock) must block INTR_FAST interrupts. > We definitely need to document what's allowed in a fast interrupt > handler. Generally as little as possible to placate the hardware and > the 'expensive' parts of the driver should be in a soft interrupt > thread. Or just in an ordinary interrupt thread. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501164354.S18480>