From owner-freebsd-arch@FreeBSD.ORG Thu May 1 00:42:46 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF8AE37B405 for ; Thu, 1 May 2003 00:42:46 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2127643FA3 for ; Thu, 1 May 2003 00:42:45 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA32516; Thu, 1 May 2003 17:41:55 +1000 Date: Thu, 1 May 2003 17:41:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "M. Warner Losh" In-Reply-To: <20030430.095215.48529965.imp@bsdimp.com> Message-ID: <20030501164354.S18480@gamplex.bde.org> References: <16047.59842.60959.352839@grasshopper.cs.duke.edu> <20030430.095215.48529965.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: phk@phk.freebsd.dk cc: gallatin@cs.duke.edu cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 07:42:47 -0000 On Wed, 30 Apr 2003, M. Warner Losh wrote: > In message: <12432.1051717236@critter.freebsd.dk> > "Poul-Henning Kamp" 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