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 00/12] cpumask handling scalability improvements

To: Jan Beulich <JBeulich@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 00/12] cpumask handling scalability improvements
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Fri, 21 Oct 2011 09:00:38 +0100
Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 21 Oct 2011 01:03:30 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=IP8BdLP03qCf2S+igMWK8HN8XkqlroB3ustpDk4+jks=; b=kgG5/agiHb6DcW18oOPaFHkPvxqcOLvxQwFLtH2+dq5qEm2XLIf0eNMr1cS/oG8Iwv HWxfo2h97DRd1SGTucUC/N/i6XKcA+adOZIPd8yF2MsxxDh8ERUfXhMTMe/9GWya53wC PHi/c1CINgtXNigivvTd/1u0qbVvG61hymyVk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4EA13711020000780005CA36@xxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcyPx4UHUwdfzi/3d06GnQAdlrjNJQ==
Thread-topic: [Xen-devel] [PATCH 00/12] cpumask handling scalability improvements
User-agent: Microsoft-Entourage/12.30.0.110427
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.

> 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.

 -- Keir



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