From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byUS2-0003fd-3V for qemu-devel@nongnu.org; Sun, 23 Oct 2016 21:53:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byURx-0004Ij-Vn for qemu-devel@nongnu.org; Sun, 23 Oct 2016 21:53:22 -0400 Received: from mail-pf0-x243.google.com ([2607:f8b0:400e:c00::243]:32914) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byURx-0004IM-MV for qemu-devel@nongnu.org; Sun, 23 Oct 2016 21:53:17 -0400 Received: by mail-pf0-x243.google.com with SMTP id i85so14950208pfa.0 for ; Sun, 23 Oct 2016 18:53:17 -0700 (PDT) References: <1475541180-16363-1-git-send-email-aik@ozlabs.ru> <9a52afb0-79d1-0b53-a271-516724b766a6@ozlabs.ru> <20161018130007.623f1fa8@nial.brq.redhat.com> <20161019142340.314438ab@nial.brq.redhat.com> From: Alexey Kardashevskiy Message-ID: <41b9cbfa-062a-e2e0-8be6-aafc3e2702ee@ozlabs.ru> Date: Mon, 24 Oct 2016 12:53:10 +1100 MIME-Version: 1.0 In-Reply-To: <20161019142340.314438ab@nial.brq.redhat.com> Content-Type: text/plain; charset=koi8-r 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: Igor Mammedov Cc: qemu-devel@nongnu.org, Greg Kurz , David Gibson On 19/10/16 23:23, Igor Mammedov wrote: > 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< 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? > > >> 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 { >>>>> >>>> >>>> >>> >> >> > -- Alexey