Re: Xen and incorporating event channels in to nr_irqs

[Thomas Gleixner]

Ian,

On Wed, 16 Feb 2011, Ian Campbell wrote:
> I'd very much like to remove this workaround (better described as a hack
> I think) but in order to do so I need to make sure there are plenty of
> IRQs between nr_irqs_gsi and nr_irqs. Effectively what we would like to
> do is:
> 	nr_irqs += NR_EVENT_CHANNELS;
> somewhere, except obviously we don't want to just drop that into generic
> code!
> 
> Do you have any hints as to an appropriate existing interface which
> could Xen use here?
> 
> If not any suggestions for what sort of interface might be acceptable to
> add?
> 
> For example I was wondering about adding x86_info.irqs.probe_nr_irqs,
> which returns a platform specific additional number of IRQs, and having
> arch_probe_nr_irqs += that value into its calculations.

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.

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/