Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 02/26/2018 01:11 PM, Chao Gao wrote:
> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote:
>>>>> On 23.02.18 at 19:11, <roger.pau@xxxxxxxxxx> wrote:
>>> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
>>>> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
>>>> ---
>>>>  xen/include/public/hvm/hvm_info_table.h | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/xen/include/public/hvm/hvm_info_table.h 
>>> b/xen/include/public/hvm/hvm_info_table.h
>>>> index 08c252e..6833a4c 100644
>>>> --- a/xen/include/public/hvm/hvm_info_table.h
>>>> +++ b/xen/include/public/hvm/hvm_info_table.h
>>>> @@ -32,7 +32,7 @@
>>>>  #define HVM_INFO_PADDR       ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
>>>>  
>>>>  /* Maximum we can support with current vLAPIC ID mapping. */
>>>> -#define HVM_MAX_VCPUS        128
>>>> +#define HVM_MAX_VCPUS        512
>>>
>>> Wow, that looks like a pretty big jump. I certainly don't have access
>>> to any box with this number of vCPUs, so that's going to be quite hard
>>> to test. What the reasoning behind this bump? Is hardware with 512
>>> ways expected soon-ish?
>>>
>>> Also osstest is not even able to test the current limit, so I would
>>> maybe bump this to 256, but as I expressed in other occasions I don't
>>> feel comfortable with have a number of vCPUs that the current test
>>> system doesn't have hardware to test with.
>>
>> I think implementation limit and supported limit need to be clearly
>> distinguished here. Therefore I'd put the question the other way
>> around: What's causing the limit to be 512, rather than 1024,
>> 4096, or even 4G-1 (x2APIC IDs are 32 bits wide, after all)?
> 
> TBH, I have no idea. When I choose a value, what comes up to my mind is
> that the value should be 288, because Intel has Xeon-phi platform which
> has 288 physical threads, and some customers wants to use this new platform
> for HPC cloud. Furthermore, they requests to support a big VM in which
> almost computing and device resources are assigned to the VM. They just
> use virtulization technology to manage the machines. In this situation,
> I choose 512 is because I feel much better if the limit is a power of 2.
> 
> You are asking that as these patches remove limitations imposed by some
> components, which one is the next bottleneck and how many vcpus does it
> limit.  Maybe it would be the use-case. No one is requesting to support
> more than 288 at this moment. So what is the value you prefer? 288 or
> 512? or you think I should find the next bottleneck in Xen's
> implementation.

I understood Jan to be responding to Roger -- Roger said he didn't want
to increase the limit beyond what osstest could reasonably test; Jan
said that what osstest can test should be factored into the *supported*
limit, not the *implementation* limit.

I agree with Jan: People should be allowed to run systems with 288
vcpus, understanding that they are at that point running essentially an
experimental system which may not work; and that if it doesn't work, it
may be that nobody will be able to reproduce and thus fix their issue.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel