From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 16:00:03 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 A37A037B401; Tue, 29 Apr 2003 16:00:03 -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 8FAE743FDF; Tue, 29 Apr 2003 16:00:02 -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 PAA87985; Tue, 29 Apr 2003 15:54:20 -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 h3TMsJ2r072779; Tue, 29 Apr 2003 15:54:19 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3TMsJ7F072778; Tue, 29 Apr 2003 15:54:19 -0700 (PDT) From: Archie Cobbs Message-Id: <200304292254.h3TMsJ7F072778@arch20m.dellroad.org> In-Reply-To: To: John Baldwin Date: Tue, 29 Apr 2003 15:54:19 -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: Archie Cobbs 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 23:00:03 -0000 John Baldwin wrote: > 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. Sure you can do that but I'm saying doing that is more complicated than necessary in some situations. > 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. I'm only advocating doing it for rare events like device insertion/removal, etc. > 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. I'd argue that complexity in one place is preferable to complexity in 100 places (ie., every device driver). -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com