Re: Xen and incorporating event channels in to nr_irqs

[Thomas Gleixner]

On Wed, 16 Feb 2011, Ian Campbell wrote:

> On Wed, 2011-02-16 at 15:56 +0000, Thomas Gleixner wrote:
> > I'm about to remove the nr_irqs NR_IRQS limitation. It's silly when we
> > deal with sparse irqs. So the idea is to have the initial nr_irqs set
> > in early boot to have a sensible size for allocating stuff. Later on
> > we can expand nr_irqs when the need arises.
> 
> > It's not only Xen which wants to eliminate the limitation. Think about
> > irq expanders which are detected late in the boot. We have no sensible
> > way to reserve enough numbers for them at early boot as we dont know
> > whether that hardware is there or not.
> > 
> > So my plan for .39 is to ignore the NR_IRQS limitation in the sparse
> > case and make nr_irqs expandable of course with a sensible upper limit
> > in the core code itself. It's basically the allocation bitmap which
> > limits it, but I doubt we'll hit 1 Million irq numbers in the
> > forseeable future.
> 
> That sounds ideal, thanks! 
> 
> I was hoping to get rid of the workaround in Xen events.c in the 2.6.39
> timeframe too.
> 
> If you let me know when you have something I can test I'll combine with
> the Xen side and give it a spin.
> 
> On a vaguely related note, what is the future of non-sparse IRQs (on x86
> and/or generally)?

In general I want to switch everything over to SPARSE_IRQ. When the
open coded access to irq_desc[] is gone, which should be mostly the
case in .39 then switching everything over should be a smooth
thing. For those archs which do not want to adjust the numbers
dynamically we simple allocate NR_IRQS in early_irq_init(). So they
wont even notice.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/