Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762843AbYFDWc3 (ORCPT ); Wed, 4 Jun 2008 18:32:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758423AbYFDWcT (ORCPT ); Wed, 4 Jun 2008 18:32:19 -0400 Received: from mx1.redhat.com ([66.187.233.31]:41397 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757923AbYFDWcS (ORCPT ); Wed, 4 Jun 2008 18:32:18 -0400 Subject: Re: [PATCH 0/7] Boot IRQ quirks and rerouting From: Jon Masters To: "Maciej W. Rozycki" Cc: Stefan Assmann , "Eric W. Biederman" , Olaf Dabrunz , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , linux-kernel@vger.kernel.org In-Reply-To: References: <12124107071847-git-send-email-od@suse.de> <4846651F.4070802@suse.de> <48467DA7.9030309@suse.de> <1212605859.8410.22.camel@londonpacket.bos.redhat.com> <1212609577.8410.32.camel@londonpacket.bos.redhat.com> Content-Type: text/plain Date: Wed, 04 Jun 2008 18:27:42 -0400 Message-Id: <1212618462.8410.46.camel@londonpacket.bos.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-4.fc8) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1682 Lines: 40 On Wed, 2008-06-04 at 23:07 +0100, Maciej W. Rozycki wrote: > On Wed, 4 Jun 2008, Jon Masters wrote: > > > I disagree. I think it's now actually the *inverse*. It /used/ to be > > harder, because you didn't have a context in which you could do many > > things (so you need to schedule some kind of deferred work), but > > actually, it'll become a lot more attractive with device threads. > > Well, I mean it's easier to do all the handling sequentially in the > hardirq context than split the thing and deal with all the communication, > locking, possible races, etc. so people avoid it unless really forced to. > In principle all the interrupt handlers could be split like this except > those really, really tiny ones or where latency is absolutely critical. > Yet it often does not happen. I'm really not proposing a return to top/bottom halves... *). Top level handler is *tiny*. It's job is to get called (along with every other such function registered for a particular IRQ line) and determine if its device generated the interrupt, and to acknowledge, preventing the device from asserting the IRQ line any longer. The top part is called in hard IRQ context, even on RT. *). Bottom level is automatically scheduled by the kernel in response to the top part acknowledging that its device caused the interrupt. The bottom part is run inside a dedicated kernel thread. So pretty much everything is in the thread. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/