From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [PATCH 0/25] Decouple IRQ issues (MSI, i386, x86_64, ia64) Date: Wed, 21 Jun 2006 09:25:37 -0700 Message-ID: <20060621162537.GC25961@kroah.com> References: <20060621102407.GA18447@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from ns.suse.de ([195.135.220.2]:54162 "EHLO mx1.suse.de") by vger.kernel.org with ESMTP id S932230AbWFUQ31 (ORCPT ); Wed, 21 Jun 2006 12:29:27 -0400 Content-Disposition: inline In-Reply-To: <20060621102407.GA18447@elte.hu> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Ingo Molnar Cc: "Eric W. Biederman" , Andrew Morton , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz, discuss@x86-64.org, Thomas Gleixner , Andi Kleen , Natalie Protasevich , Len Brown , Kimball Murray , Brice Goglin , Greg Lindahl , Dave Olson , Jeff Garzik , Greg KH , Grant Grundler , "bibo,mao" , Rajesh Shah , Mark Maule , Jesper Juhl , Shaohua Li , Matthew Wilcox , "Michael S. Tsirkin" , Ashok Raj , Randy Dunlap On Wed, Jun 21, 2006 at 12:24:07PM +0200, Ingo Molnar wrote: > > * Eric W. Biederman wrote: > > > The following patchset is against 2.6.17-rc6-mm2. It was the only easy > > place I could get everyones work who has been touching relevant code. > > > > The primary aim of this patch is to remove maintenances problems > > caused by the irq infrastructure. The two big issues I address are an > > artificially small cap on the number of irqs, and that MSI assumes > > vector == irq. My primary focus is on x86_64 but I have touched other > > architectures where necessary to keep them from breaking. > > Very nice! Your queue addresses all of the remaining grievances i had > about the x86_64/i386 IRQ code (MSI/balancing) and does this ontop of > genirq, which is very good. This is much more than i hoped for when you > told us about your project! :) > > The only open bigger issue i guess (besides all the smaller code details > that i'm sure we'll sort out) is timing. Your queue, as tempting as it > is, is probably not 2.6.18 material. _I_ would certainly dare this for > 2.6.18, but Andrew/Linus would kill me i guess. No, it needs to sit in -mm for a while. All of the new 2.6.18 stuff already has been in there, this is a bit too late for it. I have no problem with taking this and letting it get beat on for a few months and then go into 2.6.19. > So the question is - are we brave/confident enough to try to stabilize > this in the next couple of days and drop it into 2.6.18 together with > the other bits of genirq? No, see above please. > I strongly suspect that the bugs this patchset will introduce is > roughly equal to the bugs we already have due to the existing MSI and > irq-balancing unrobustnesses, so we might as well go for that, instead > of prolonging the pain by doing a two-stage (or 3-stage) process. > (which would be to introduce genirq stage #1 now, then introduce > genirq stage #2 in 2.6.19) Delaying genirq to 2.6.19 altogether would > be messy i think and would interfere with ben's (and others') platform > plans. Hm? I don't object to genirq to go in now for 2.6.18, but this series is too new. Incremental changes please :) thanks, greg k-h