Message ID | 146297487258.12455.11591484741503224557.stgit@bahia.huguette.org |
---|---|
State | New |
Headers | show |
On Wed, 11 May 2016 16:00:04 +0200 Greg Kurz <gkurz@linux.vnet.ibm.com> wrote: > 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> > --- > > This was tested with a pseries guest only. I'd like to know if it is okay > for other platforms. #git grep MAX_CPUMASK_BITS ... hw/arm/virt.c: mc->max_cpus = MAX_CPUMASK_BITS; hw/ppc/spapr.c: mc->max_cpus = MAX_CPUMASK_BITS; ... you probably don't want to change all those to 1024, see/review a similar patch where I bump it upto 288 bits https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg01101.html in addition where does 1024 come from? is pseries capable to provide that many CPUs? > > 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 38fb3cad35e1..89d742caa477 100644 > --- a/include/sysemu/sysemu.h > +++ b/include/sysemu/sysemu.h > @@ -185,7 +185,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 { >
On Wed, 11 May 2016 16:20:08 +0200 Igor Mammedov <imammedo@redhat.com> wrote: > On Wed, 11 May 2016 16:00:04 +0200 > Greg Kurz <gkurz@linux.vnet.ibm.com> wrote: > > > 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> > > --- > > > > This was tested with a pseries guest only. I'd like to know if it is okay > > for other platforms. > #git grep MAX_CPUMASK_BITS > ... > hw/arm/virt.c: mc->max_cpus = MAX_CPUMASK_BITS; > hw/ppc/spapr.c: mc->max_cpus = MAX_CPUMASK_BITS; > ... > > you probably don't want to change all those to 1024, Well, at least the spapr one :) > see/review a similar patch where I bump it upto 288 bits > https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg01101.html > Indeed... I should set it to 255 in hw/arm/virt.c. Thanks for pointing that out. > > in addition where does 1024 come from? All PowerPC distros I could check support either 1024 (PowerKVM, Fedora) or 2048 (Ubuntu, RHEL7) vCPUs in KVM. I've chosen 1024 because of PowerKVM :) > is pseries capable to provide that many CPUs? > Yes. > > > > 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 38fb3cad35e1..89d742caa477 100644 > > --- a/include/sysemu/sysemu.h > > +++ b/include/sysemu/sysemu.h > > @@ -185,7 +185,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 { > > >
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h index 38fb3cad35e1..89d742caa477 100644 --- a/include/sysemu/sysemu.h +++ b/include/sysemu/sysemu.h @@ -185,7 +185,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 {
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> --- This was tested with a pseries guest only. I'd like to know if it is okay for other platforms. include/sysemu/sysemu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)