Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752743AbdHKILI (ORCPT ); Fri, 11 Aug 2017 04:11:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56264 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751512AbdHKILF (ORCPT ); Fri, 11 Aug 2017 04:11:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 127B822C8C1 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=david@redhat.com Subject: Re: [PATCH] KVM/x86: Increase max vcpu number to 352 To: Lan Tianyu , Konrad Rzeszutek Wilk , rkrcmar@redhat.com Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <1502359259-24966-1-git-send-email-tianyu.lan@intel.com> <20170810175056.GR2547@char.us.oracle.com> <23159a7e-463a-2a5b-5aaa-ef7f0eb43547@intel.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Fri, 11 Aug 2017 10:11:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <23159a7e-463a-2a5b-5aaa-ef7f0eb43547@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 11 Aug 2017 08:11:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1835 Lines: 53 On 11.08.2017 09:49, Lan Tianyu wrote: > Hi Konrad: > Thanks for your review. > > On 2017年08月11日 01:50, Konrad Rzeszutek Wilk wrote: >> On Thu, Aug 10, 2017 at 06:00:59PM +0800, Lan Tianyu wrote: >>> Intel Xeon phi chip will support 352 logical threads. For HPC usage >>> case, it will create a huge VM with vcpu number as same as host cpus. This >>> patch is to increase max vcpu number to 352. >> >> Why not 1024 or 4096? > > This is on demand. We can set a higher number since KVM already has > x2apic and vIOMMU interrupt remapping support. > >> >> Are there any issues with increasing the value from 288 to 352 right now? > > No found. > >> >> Also perhaps this should be made in an Kconfig entry? > > That will be anther option but I find different platforms will define > different MAX_VCPU. If we introduce a generic Kconfig entry, different > platforms should have different range. > > Radim & Paolo, Could you give some input? In qemu thread, we will set > max vcpu to 8192 for x86 VM. In KVM, The length of vcpu pointer array in > struct kvm and dest_vcpu_bitmap in kvm_irq_delivery_to_apic() are > specified by KVM_MAX_VCPUS. Should we keep align with Qemu? > commit 682f732ecf7396e9d6fe24d44738966699fae6c0 Author: Radim Krčmář Date: Tue Jul 12 22:09:29 2016 +0200 KVM: x86: bump MAX_VCPUS to 288 288 is in high demand because of Knights Landing CPU. We cannot set the limit to 640k, because that would be wasting space. I think we want to keep it small as long as possible. I remember a patch series from Radim which would dynamically allocate memory for these arrays (using a new VM creation ioctl, specifying the max # of vcpus). Wonder what happened to that (I remember requesting a simply remalloc instead of a new VM creation ioctl :] ). -- Thanks, David