| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] x86: eliminate hard-coded NR_IRQS
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 20.05.09 15:48 >>>
>On 20/05/2009 06:16, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>> ... splitting it into global nr_irqs (determined at boot time) and per-
>> domain nr_pirqs (derived from nr_irqs and a possibly command line
>> specified value, which probably should later become a per-domain config
>> setting).
>>
>> This has the (desirable imo) side effect of reducing the size of struct
>> hvm_irq_dpci from requiring an order-3 page to order-2 (on x86-64),
>> which nevertheless still is too large.
>
>Erm, well I'm not sure about this patch. Your single stated motivation, to
>reduce some struct sizes, could also be addressed by replacing arrays with
>other really simple alternatives like hash tables or radix trees. Or
>replacing in-place arrays with pointers to arrays (which obviously you do in
>some places out of necessity in your patch, but that could equally be done
>without making nr_irqs/nr_pirqs dynamic).
No, that wasn't the motivation - as I said this is just a nice side effect.
>Does it make sense to have nr_pirqs > nr_irqs? Are you thinking of a shared
Yes - nr_irqs is only what comes through the IO-APIC. nr_pirqs includes MSI
sources (which only require vectors, and with vector and irq spaces now
properly separated, including them in the irq space is no longer needed).
Thus nr_pirqs generally *must* be larger than nr_irqs.
>irq being exposed to a guest as non-shared multiple pirqs? Basically I
>thought the setting of nr_pirqs based on nr_irqs plus some command-line
>values looks a bit bizarre and kludgy and I'm not sure what the usage
>scenario is there.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home