Re: [RFC PATCH 0/5] Extend resources to support more vcpus in single VM

From: "Jan Beulich" <JBeulich@suse.com>
To: Lan Tianyu <tianyu.lan@intel.com>
Cc: kevin.tian@intel.com, Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Meng Xu <xumengpanda@gmail.com>,
	chao.gao@intel.com
Subject: Re: [RFC PATCH 0/5] Extend resources to support more vcpus in single VM
Date: Wed, 30 Aug 2017 01:12:39 -0600	[thread overview]
Message-ID: <59A6818702000078001755D7@prv-mh.provo.novell.com> (raw)
In-Reply-To: <bd84adf1-dff8-5a79-0f7e-78eba480edfd@intel.com>

>>> On 30.08.17 at 07:33, <tianyu.lan@intel.com> wrote:
> On 2017年08月29日 16:49, Jan Beulich wrote:
>>>>> On 29.08.17 at 06:38, <tianyu.lan@intel.com> wrote:
>>> On 2017年08月25日 22:10, Meng Xu wrote:
>>>> How many VCPUs for a single VM do you want to support with this patch set?
>>>
>>> Hi Meng:
>>> 	Sorry for later response. We hope to increase max vcpu number to 512.
>>> This also have dependency on other jobs(i.e, cpu topology, mult page
>>> support for ioreq server and virtual IOMMU).
>> 
>> I'm sorry for repeating this, but your first and foremost goal ought
>> to be to address the known issues with VMs having up to 128
>> vCPU-s; Andrew has been pointing this out in the past. I see no
>> point in pushing up the limit if even the current limit doesn't work
>> reliably in all cases.
>> 
> 
> Hi Jan & Andrew:
> 	We ran some HPC benchmark(i.e, HPlinkpack, dgemm, sgemm, igemm and so
> on) in a huge VM with 128 vcpus(Even >255 vcpus with non-upstreamed
> patches) and didn't meet unreliable issue. These benchmarks run heavy
> workloads in VM and some of them even last several hours.

I guess it heavily depends on what portions of hypervisor code
those benchmarks exercise. Compute-intensives ones (which
seems a likely case for HPC) aren't that interesting. Ones putting
high pressure on e.g. the p2m lock, or ones causing high IPI rates
(inside the guest) are likely to be more problematic.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel