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] [pv-ops domU] support MAXSMP

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [pv-ops domU] support MAXSMP
From: Andrew Jones <drjones@xxxxxxxxxx>
Date: Fri, 18 Dec 2009 14:23:00 +0100
Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 18 Dec 2009 05:28:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B2B585D.5000305@xxxxxxxxxx>
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>
References: <4B2B4BF3.1010507@xxxxxxxxxx> <4B2B625D02000078000269B3@xxxxxxxxxxxxxxxxxx> <4B2B585D.5000305@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091109 Fedora/3.0-3.10.b4.fc12 Lightning/1.0pre Thunderbird/3.0b4
On 12/18/2009 11:24 AM, Andrew Jones wrote:
On 12/18/2009 11:07 AM, Jan Beulich wrote:
Andrew Jones<drjones@xxxxxxxxxx> 18.12.09 10:31>>>
The MAXSMP config option requires CPUMASK_OFFSTACK, which in turn
requires we init the memory for the maps while we bringing up the cpus.
MAXSMP also increases NR_CPUS to 4096. This increase in size exposed an
issue in the argument construction for mulitcalls from
xen_flush_tlb_others. The args should only need space for the actual
number of cpus, which with xen is currently only up to 32.

I don't think new code should be making assumptions like this anymore,
since Xen already supports higher numbers (it's merely the tools which
so far don't). You're basically trading a compile time detectable large
value on stack for one that can grow large dynamically (and hence
require quite a bit more effort to debug, should it ever overrun the
stack).

I say 32 cpus in my description to point out the large difference
between NR_CPUS and the actual number used. However, the code shouldn't
exceed the limits in multicall until something around 2000 cpus.

Keeping it compile-time is good for the stack analysis, but overly
wasteful when using values like 4096, since the expected case is
thousands less. If we want to keep it static then we need to change
MC_ARGS to also be dependent in some way on NR_CPUS.


Another note here is that the amount of stack allocation is the same regardless of the value of num_processors. We're just creating a pointer to this structure on the stack. sizeof is smart enough to pass the appropriate dynamic size on to the mc call for validation though. So I think all should be good with this patch.

Andrew

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