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

Re: [Xen-devel] [PATCH 1/2] IRQ: allocate CPU masks dynamically

>>> On 03.11.11 at 16:43, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 03/11/11 15:17, Jan Beulich wrote:
>>>>> On 03.11.11 at 15:49, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 03/11/11 14:26, Jan Beulich wrote:
>>>> IRQ: allocate CPU masks dynamically
>>>>
>>>> This includes delaying the initialization of dynamically created IRQs
>>>> until their actual first use and some further elimination of uses of
>>>> struct irq_cfg.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>
>>> One query which may or may not affect the patch.  Would we get better
>>> caching characteristics if all cpumasks were allocated in consecutive
>>> memory, rather than having 3 individual allocs in arch_init_one_irq_desc ?
>> That was what the first version of the patch did, rejected by Keir
>> (and not liked too much by me either).
>>
>> Jan
> 
> My understanding of the objection was hiding the variables themselves as
> an array in the code.
> 
> An alternative approach such as alloc'ing 3*sizeof(cpu mask) (cache
> aligned) and assigning the relevant pointers to the current
> cpumask_var_t's would be a suitable approach which causes the cpumasks
> to be in contiguous memory, but not changing how they are referenced in
> the code.

That would mean just open-coding what the former patch did by
abstraction. In my opinion that is even worse - either we want a
generally usable mechanism to do this, or we don't do it at all.

Jan


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