| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] [pv-ops domU] support MAXSMP
----- Original Message -----
> On Fri, Dec 18, 2009 at 02:23:00PM +0100, Andrew Jones wrote:
> > 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,
>
> Are you carrying this patch in Fedora? Is there a newer version of
> this patch that you have?
Not in Fedora, it's only in RHEL. From a quick look I don't believe the
patch would need to be changed for the current kernel, but I haven't tried
it.
Drew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home