Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761983AbYFDWIt (ORCPT ); Wed, 4 Jun 2008 18:08:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754009AbYFDWIm (ORCPT ); Wed, 4 Jun 2008 18:08:42 -0400 Received: from kirk.serum.com.pl ([213.77.9.205]:62900 "EHLO serum.com.pl" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757778AbYFDWIl (ORCPT ); Wed, 4 Jun 2008 18:08:41 -0400 Date: Wed, 4 Jun 2008 23:07:52 +0100 (BST) From: "Maciej W. Rozycki" To: Jon Masters cc: Stefan Assmann , "Eric W. Biederman" , Olaf Dabrunz , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/7] Boot IRQ quirks and rerouting In-Reply-To: <1212609577.8410.32.camel@londonpacket.bos.redhat.com> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1477 Lines: 30 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. > The only real caveat is for performance critical cases (the reasons we > have special softirqs and the like right now) but there will always be > special cases. Still, I'd like it if writing a Linux interrupt handler > came down to registering two functions - one lightweight tiny one, and > one that's just a thread. Much less room for making mistakes. The two will have to pass some state between each other, might run concurrently or in parallel, etc. and require some effort to be written correctly. Maciej -- 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/