Re: [Qemu-devel] [PATCH qemu] sysemu: support up to 1024 vCPUs

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 24 Oct 2016 12:53:10 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> On 19/10/16 23:23, Igor Mammedov wrote:
> > On Wed, 19 Oct 2016 10:39:12 +1100
> > Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >   
> >> On 18/10/16 22:00, Igor Mammedov wrote:  
> >>> On Tue, 11 Oct 2016 09:19:10 +1100
> >>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >>>     
> >>>> Ping, anyone?    
> >>> I have a similar patch
> >>> http://patchwork.ozlabs.org/patch/681709/
> >>> which bumps limit to 288 and does a little bit more
> >>> so it wouldn't affect current users.    
> >>
> >> Why 288 (not oldlimit<<n)? :)  
> > That's how many vCPU we plan to support for target-i386.  
> 
> 
> So that patch from patchworks should actually be 3 patches -
> - untie MAX_CPUMASK_BITS from maxcpus;
> - increase MAX_CPUMASK_BITS to 1024 (till we get this thing totally dynamic);
> - increase maxcpus for x86 to 288.
> 
> and on top of this I (or Greg) would repost pseries change to maxcpus=1024
> 
> Correct? Has your patch gone anywhere yet?
It's been reviewed and I expect it merged soon.

on top of it 
MAX_CPUMASK_BITS could be bumped up along with pseries.maxcpus

 
> >   
> >> What does happen to the Greg's patch now?  
> > it could be amended to apply top of above patch,
> > 
> > where it would change not only MAX_CPUMASK_BITS but also
> > maxcpus in ppc target since above patch unties maxcpus
> > from MAX_CPUMASK_BITS for all targets.
> > 
> > So followup increases of MAX_CPUMASK_BITS won't affect
> > other targets.
> >   
> >>
> >>  
> >>>
> >>> After that's merged, I plan to get rid of this limit and
> >>> make that part of numa parsing code dynamic so that it
> >>> wouldn't impose such limit/any limits on target code.
> >>>     
> >>>>
> >>>>
> >>>> On 04/10/16 11:33, Alexey Kardashevskiy wrote:    
> >>>>> From: Greg Kurz <gkurz@linux.vnet.ibm.com>
> >>>>>
> >>>>> Some systems can already provide more than 255 hardware threads.
> >>>>>
> >>>>> Bumping the QEMU limit to 1024 seems reasonable:
> >>>>> - it has no visible overhead in top;
> >>>>> - the limit itself has no effect on hot paths.
> >>>>>
> >>>>> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
> >>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>>>> ---
> >>>>>  include/sysemu/sysemu.h | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> >>>>> index ef2c50b..2ec0bd8 100644
> >>>>> --- a/include/sysemu/sysemu.h
> >>>>> +++ b/include/sysemu/sysemu.h
> >>>>> @@ -173,7 +173,7 @@ extern int mem_prealloc;
> >>>>>   *
> >>>>>   * Note that cpu->get_arch_id() may be larger than MAX_CPUMASK_BITS.
> >>>>>   */
> >>>>> -#define MAX_CPUMASK_BITS 255
> >>>>> +#define MAX_CPUMASK_BITS 1024
> >>>>>  
> >>>>>  #define MAX_OPTION_ROMS 16
> >>>>>  typedef struct QEMUOptionRom {
> >>>>>       
> >>>>
> >>>>    
> >>>     
> >>
> >>  
> >   
> 
>