Re: [PATCH] [pv-ops domU] support MAXSMP

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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@redhat.com> 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?