From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 17:12:02 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 48BC537B401; Tue, 29 Apr 2003 17:12:02 -0700 (PDT) Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5EB343F93; Tue, 29 Apr 2003 17:11:59 -0700 (PDT) (envelope-from dufault@hda.com) Received: from hda.com (skinny.hda.com [198.252.184.80]) by hda.hda.com (8.11.6/8.11.6) with ESMTP id h3U0N1w92947; Tue, 29 Apr 2003 20:23:02 -0400 (EDT) (envelope-from dufault@hda.com) Date: Tue, 29 Apr 2003 20:11:56 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Archie Cobbs From: Peter Dufault In-Reply-To: <200304292254.h3TMsJ7F072778@arch20m.dellroad.org> Message-Id: <5AC4B3BA-7AA0-11D7-BD29-000393B2C586@hda.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: Poul-Henning Kamp 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: Wed, 30 Apr 2003 00:12:02 -0000 On Tuesday, Apr 29, 2003, at 18:54 US/Eastern, Archie Cobbs wrote: > 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). > The issue is promoting not thinking about what context you're working in. It makes sense to have a clean API for kicking off a worker thread, but "automagic" threads that kick in due to lack of thinking out how things work aren't ready for prime time. To do what you're recommending, use a "Permit me to be naive" flag. That puts the complexity in one place recognizing that it might not be the best place. Peter Peter Dufault (dufault@hda.com)