WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Xen and incorporating event channels in to nr_irqs

To: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: Xen and incorporating event channels in to nr_irqs
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Wed, 16 Feb 2011 16:12:19 +0000
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Wed, 16 Feb 2011 08:13:04 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.LFD.2.00.1102161638320.2701@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1297868399.16356.180.camel@xxxxxxxxxxxxxxxxxxxxxx> <alpine.LFD.2.00.1102161638320.2701@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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)?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel