From: David Hildenbrand <david@redhat.com>
To: Lan Tianyu <tianyu.lan@intel.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
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
Subject: Re: [PATCH] KVM/x86: Increase max vcpu number to 352
Date: Fri, 11 Aug 2017 10:11:01 +0200 [thread overview]
Message-ID: <aab6d4cc-770c-4c49-c587-ff693e23388f@redhat.com> (raw)
In-Reply-To: <23159a7e-463a-2a5b-5aaa-ef7f0eb43547@intel.com>
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ář <rkrcmar@redhat.com>
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
next prev parent reply other threads:[~2017-08-11 8:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-10 10:00 Lan Tianyu
[not found] ` <20170810175056.GR2547@char.us.oracle.com>
2017-08-11 7:49 ` Lan Tianyu
2017-08-11 8:11 ` David Hildenbrand [this message]
2017-08-11 13:00 ` Radim Krčmář
2017-08-11 19:35 ` Konrad Rzeszutek Wilk
2017-08-15 3:00 ` Lan Tianyu
2017-08-15 14:10 ` Konrad Rzeszutek Wilk
2017-08-15 16:13 ` Radim Krčmář
2017-08-18 13:57 ` Konrad Rzeszutek Wilk
2017-08-21 15:44 ` Radim Krčmář
2017-08-16 3:07 ` Lan Tianyu
2017-08-18 14:20 ` Konrad Rzeszutek Wilk
2017-08-15 14:20 ` Radim Krčmář
2017-08-11 22:47 ` Denys Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aab6d4cc-770c-4c49-c587-ff693e23388f@redhat.com \
--to=david@redhat.com \
--cc=hpa@zytor.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=tianyu.lan@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome