lkml.org 
[lkml]   [2006]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/25] Decouple IRQ issues (MSI, i386, x86_64, ia64)
On Wed, Jun 21, 2006 at 12:24:07PM +0200, Ingo Molnar wrote:
>
> * Eric W. Biederman <ebiederm@xmission.com> 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
-
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/

\
 
 \ /
  Last update: 2006-06-21 18:31    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site