On Tue, 18 Oct 2016 13:00:07 +0200 Igor Mammedov <imamm...@redhat.com> wrote:
> On Tue, 11 Oct 2016 09:19:10 +1100 > Alexey Kardashevskiy <a...@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. > Heh the bumping to 1024 was kinda arbitrary but 288 would be an improvement anyway. FYI, only Alpine class servers would benefit from that since they have 320 threads, even if they're not officially supported to run a KVM based hypervisor (biggest supported model is Tuleta with 192 threads). BTW, the afore mentioned patch keeps the current 255 limit for pseries machine types. I guess David's answer means that the hw/ppc/spapr.c hunk can be safely dropped. > 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 <gk...@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 <gk...@linux.vnet.ibm.com> > > > Signed-off-by: Alexey Kardashevskiy <a...@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 { > > > > > > > >
