From owner-freebsd-arch@FreeBSD.ORG  Tue Apr 29 16:44:33 2003
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 280F037B401; Tue, 29 Apr 2003 16:44:33 -0700 (PDT)
Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 14AE943F85; Tue, 29 Apr 2003 16:44:32 -0700 (PDT)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost [127.0.0.1])
	by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3TNiTA7093598;
	Tue, 29 Apr 2003 17:44:29 -0600 (MDT)
	(envelope-from imp@harmony.village.org)
Message-Id: <200304292344.h3TNiTA7093598@harmony.village.org>
To: Archie Cobbs <archie@dellroad.org>
In-reply-to: Your message of "Tue, 29 Apr 2003 15:54:19 PDT."
		<200304292254.h3TMsJ7F072778@arch20m.dellroad.org> 
References: <200304292254.h3TMsJ7F072778@arch20m.dellroad.org>  
Date: Tue, 29 Apr 2003 17:44:29 -0600
From: Warner Losh <imp@harmony.village.org>
cc: Poul-Henning Kamp <phk@phk.freebsd.dk>
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
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Apr 2003 23:44:33 -0000

In message <200304292254.h3TMsJ7F072778@arch20m.dellroad.org> Archie Cobbs writes:
: >           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.

You shouldn't be doing attach/detach from an interrupt context, but
rather from a thread context.  Right now there's no locking, so it
works, but when locking goes in you might not be able do so.  Depends
on the choice of lock I have: faster spin locks wouldn't work, but
slower mutexes would.

Warner