>>> On 21.10.11 at 10:00, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 21/10/2011 08:10, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>
>>> Aren't we planning to dynamically allocate irq_desc-s? That would seem the
>>> nicer solution here.
>>
>> Yes, I would hope so. But irrespective of that, allocating e.g. 512 bits
>> (times 4) just to use, say, 20-30 of them is bad - again, not so much
>> from a memory wasting pov, but rather from the fact that this
>> needlessly causes a larger cache and TLB footprint.
>
> Oh, I don't mind you changing irq_desc to use cpumask_var_t-s. It's the
> extra step of using an array to save a few pointers, that I reject.
That's what I understood.
>> I actually think that ultimately we should try to remove all
>> non-dynamically allocated CPU masks (including statics, per-CPU
>> ones, and local variables - the latter being particularly important as
>> they cause pretty big stack frames, despite there now being at
>> most one [with the rare exception of two] of them per function,
>> which will continue to grow with higher NR_CPUS values).
>
> OTOH they are probably in some cases used in contexts where dynamic
> allocation (and possibility of failure) is not nice? And we can compare this
> effort with just increasing per-cpu stack sizes, for example?
>
> I'm not particularly against moving in this direction, but there might be
> cases where it isn't worth the effort, or there are better solutions.
Indeed, in some cases it may mean moving from stack variables to
e.g. per-CPU pre-allocated ones.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home