Re: [Xen-devel] RFC: vNUMA project

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 12/11/14 14:27, Wei Liu wrote:
> On Wed, Nov 12, 2014 at 02:13:09PM +0000, Jan Beulich wrote:
>>>>> On 12.11.14 at 14:45, <wei.liu2@xxxxxxxxxx> wrote:
>>> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
>>>>>>> On 11.11.14 at 19:03, <david.vrabel@xxxxxxxxxx> wrote:
>>>>> On 11/11/14 17:36, Wei Liu wrote:
>>>>>> Option #1 requires less modification to guest, because guest won't
>>>>>> need to switch to new hypercall. It's unclear at this point if a guest
>>>>>> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>>>>>> should do about it. Should it be permissive or strict? 
>>>>>
>>>>> There are XENMEMF flags to request exact node or not  -- leave it up to
>>>>> the balloon driver.  The Linux balloon driver could try exact on all
>>>>> nodes before falling back to permissive or just always try inexact.
>>>>>
>>>>> Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
>>>>
>>>> Yes. The only bad thing here is that we don't currently check in the
>>>> hypervisor that unknown bits are zero, i.e. code using the new flag
>>>> will need to have a separate means to find out whether the bit is
>>>> supported. Not a big deal of course.
>>>>
>>>
>>> If this new bit is set and domain has vnuma, then it's valid
>>> (supported); otherwise it's not.
>>>
>>> To not break existing guests, we can fall back to non-vnuma hinted
>>> allocation when the new bit is set and vnuma is not available.
>>
>> While this is valid, none of this was my point - I was talking about a
>> new guest running on an older hypervisor.
>>
> 
> That would not cause breakage. Even if the guest sets this new bit it's
> ignored by Xen. Guest can still balloon up, though the end result is
> sub-optimal.

No. Because it will get memory allocated from the specified /physical/
node which would be quite wrong.

David

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