From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 11:04:51 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 35D3E37B405 for ; Tue, 29 Apr 2003 11:04:51 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CA043FBF for ; Tue, 29 Apr 2003 11:04:50 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11711 invoked from network); 29 Apr 2003 18:04:54 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 29 Apr 2003 18:04:54 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3TI4kOv018960; Tue, 29 Apr 2003 14:04:46 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200304290438.h3T4cdHE069528@arch20m.dellroad.org> Date: Tue, 29 Apr 2003 14:04:51 -0400 (EDT) From: John Baldwin To: Archie Cobbs 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 18:04:51 -0000 On 29-Apr-2003 Archie Cobbs wrote: > 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.). If you need to do more work in your interrupt routine than just wakeups and dinking with registers, you can always wake up a software interrupt handler or some other random kthread to do things that take a long amount of time. Sleeping in an interrupt thread would destroy interrupt latency far worse than it is now. I'm sure we can all agree that that would be unacceptable. Rather than making the interrupt thread implementation very complex with magical spawning kthreads and such, I would prefer that driver authors kick up software interrupt threads and the like on their own and keep the ithread implementation simple. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/