[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] NR_PIRQS vs. NR_IRQS


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Thu, 13 Nov 2008 19:19:38 +0000
  • Cc:
  • Delivery-date: Thu, 13 Nov 2008 11:20:03 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AclFv27+rUoHrrGyEd2xqwAWy6hiGQABVYiV
  • Thread-topic: [Xen-devel] NR_PIRQS vs. NR_IRQS

On 13/11/08 18:41, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> PIRQs are actually a different namespace. They aren't necessarily 1:1
> mapped. Hence NR_PIRQS and NR_IRQS not really same thing.

However I'll agree that in some cases it's assumed that the namespaces are
the same size (PHYSDEVOP_alloc_irq_vector pretty much does that). And they
*are* being used rather interchangeably already... So yes, actually perhaps
we should kill off NR_PIRQS. It seems not worth cleaning up usage of NR_IRQS
vs NR_PIRQS to make the distinction clean and correct.

> Yes, I'm sure with a bit of finessing we could have NR_IRQS != NR_VECTORS.
> I'm sure there'll be some barking NUMA box down the road that will require
> something like that, but thankfully not so far.

I agree with keeping this naming distinction of course, although I think
allowing NR_IRQS > NR_VECTORS right now is not very useful. But maybe you
have a box in mind that needs it?

 -- Keir

>  -- Keir
> 
> On 13/11/08 16:59, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> 
>> I'm having some difficulty understanding why these two need to be
>> distinguished: Depending on the code location, an IRQ passed in from the
>> guest may be checked against NR_PIRQS (map_domain_pirq() as called
>> from PHYSDEVOP_alloc_irq_vector) or NR_IRQS (PHYSDEVOP_irq_status_query,
>> PHYSDEVOP_map_pirq), despite it having the same source.
>> 
>> Also, tying NR_IRQS to NR_VECTORS seems bogus - even with current
>> code I can't see why we shouldn't be able to support a higher NR_IRQS
>> without immediately doing the more involved code changes needed to
>> also grow NR_VECTORS. After all, NR_IRQS is directly tied to the number
>> of IO-APIC pins we can support - in order to support a device, its
>> cumulative pin number (being the irq) must be below NR_IRQS. But since
>> very likely not all pins are connected to devices, NR_VECTORS is much
>> less of a limiting factor.
>> 
>> Thanks, Jan
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.