From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bybTG-0001ZB-8U for qemu-devel@nongnu.org; Mon, 24 Oct 2016 05:23:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bybTD-0004yv-4v for qemu-devel@nongnu.org; Mon, 24 Oct 2016 05:23:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57018) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bybTC-0004xt-Jd for qemu-devel@nongnu.org; Mon, 24 Oct 2016 05:23:03 -0400 Date: Mon, 24 Oct 2016 11:22:58 +0200 From: Igor Mammedov Message-ID: <20161024112258.3d3714cb@nial.brq.redhat.com> In-Reply-To: <41b9cbfa-062a-e2e0-8be6-aafc3e2702ee@ozlabs.ru> 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> <41b9cbfa-062a-e2e0-8be6-aafc3e2702ee@ozlabs.ru> 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 Mon, 24 Oct 2016 12:53:10 +1100 Alexey Kardashevskiy wrote: > 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? It's been reviewed and I expect it merged soon. on top of it MAX_CPUMASK_BITS could be bumped up along with pseries.maxcpus > > > >> 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 { > >>>>> > >>>> > >>>> > >>> > >> > >> > > > >