From owner-freebsd-smp@FreeBSD.ORG  Tue Apr 22 17:47:04 2003
Return-Path: <owner-freebsd-smp@FreeBSD.ORG>
Delivered-To: freebsd-smp@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 334BC37B401
	for <freebsd-smp@FreeBSD.org>; Tue, 22 Apr 2003 17:47:01 -0700 (PDT)
Received: from aramis.rutgers.edu (aramis.rutgers.edu [128.6.4.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 62B3843FBF
	for <freebsd-smp@FreeBSD.org>; Tue, 22 Apr 2003 17:47:00 -0700 (PDT)
	(envelope-from bohra@cs.rutgers.edu)
Received: from cs.rutgers.edu (bohra.resnet.rutgers.edu [172.23.24.127])
	by aramis.rutgers.edu (8.11.7+Sun/8.8.8) with ESMTP id h3N0kxk12529
	for <freebsd-smp@FreeBSD.org>; Tue, 22 Apr 2003 20:46:59 -0400 (EDT)
Message-ID: <3EA5E29F.9000801@cs.rutgers.edu>
Date: Tue, 22 Apr 2003 20:47:27 -0400
From: Aniruddha Bohra <bohra@cs.rutgers.edu>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US;
	rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-smp@FreeBSD.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Question about interrupt threads
X-BeenThere: freebsd-smp@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: FreeBSD SMP implementation group <freebsd-smp.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-smp>,
	<mailto:freebsd-smp-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-smp>
List-Post: <mailto:freebsd-smp@freebsd.org>
List-Help: <mailto:freebsd-smp-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-smp>,
	<mailto:freebsd-smp-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2003 00:47:04 -0000

Hello
    I am posting it again to -smp as advised by Kris

Reading the implementation of interrupt handling on i386,
and reading Greg Lehey's Usenix paper on FreeBSD 5.0 SMP
implementation, I understand that interrupt handling is done in
process context. This is needed partly to support sleeping while
handling the interrupt because GIANT needs to be locked and
a sleep is possible there.

   My question is after all subsystems that lock giant are made
INTR_MPSAFE will the implementation go back to non-process
context interrupt handling (as in older versions) ?

   Moreover, will the locking be per-IRQ or there will be a
global IRQ lock for ensuring atomic access to the ISRs ?

   Finally why do we need to create a kernel thread for
each IRQ - why can't one kernel thread handle all the
IRQs ?

    Thanks

Aniruddha