From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwpuN-0007pQ-FN for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:23:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwpuK-0003So-Be for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:23:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52834) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwpuK-0003SR-6M for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:23:44 -0400 Date: Wed, 19 Oct 2016 14:23:40 +0200 From: Igor Mammedov Message-ID: <20161019142340.314438ab@nial.brq.redhat.com> In-Reply-To: References: <1475541180-16363-1-git-send-email-aik@ozlabs.ru> <9a52afb0-79d1-0b53-a271-516724b766a6@ozlabs.ru> <20161018130007.623f1fa8@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu] sysemu: support up to 1024 vCPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: qemu-devel@nongnu.org, Greg Kurz , David Gibson On Wed, 19 Oct 2016 10:39:12 +1100 Alexey Kardashevskiy wrote: > On 18/10/16 22:00, Igor Mammedov wrote: > > On Tue, 11 Oct 2016 09:19:10 +1100 > > Alexey Kardashevskiy 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< 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 > >>> > >>> 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 > >>> Signed-off-by: Alexey Kardashevskiy > >>> --- > >>> 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 { > >>> > >> > >> > > > >