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. 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 { > > > >
