From owner-freebsd-arch@FreeBSD.ORG Mon Apr 28 21:45:10 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 63DD137B401; Mon, 28 Apr 2003 21:45:10 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6759843FA3; Mon, 28 Apr 2003 21:45:09 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA81756; Mon, 28 Apr 2003 21:38:40 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3T4cd2r069529; Mon, 28 Apr 2003 21:38:39 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3T4cdHE069528; Mon, 28 Apr 2003 21:38:39 -0700 (PDT) From: Archie Cobbs Message-Id: <200304290438.h3T4cdHE069528@arch20m.dellroad.org> In-Reply-To: <20030426231749.H48182@gamplex.bde.org> To: Bruce Evans Date: Mon, 28 Apr 2003 21:38:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: Poul-Henning Kamp cc: gibbs@FreeBSD.ORG 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: Tue, 29 Apr 2003 04:45:10 -0000 Bruce Evans wrote: > > I would tend to think that while sleeping in interrupt threads > > should be avoided, it should only be avoided "at reasonable cost", > > not "at any cost". > > I think it may actually work now in some cases, since there is now an > ithread context to sleep on, but camisr() in general is not such a [ moving this followup to -arch ] Random thought.. it's always seemed unnatural to me to say that interrupt threads can't sleep. Why couldn't the system be designed so that if an interrupt thread tried to sleep, it would actually sleep but atomically (a) detach itself from the interrupt and (b) spawn a new thread to handle future interrupts. I.e., sleep with "on demand" additional interrupt thread creation. To avoid reentrancy problems, we would probably also want to block re-entry into the same interrupt handler function until the original handler returned. If you did this, code wouldn't have to "know" whether it was running in an interrupt. Of course, for efficiency you don't want to do a lot of sleeping while handling interrupts, but in practice the need to probably only arises very rarely (e.g., insertion/removal, ifconfig up/down, etc.). -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com