[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: vNUMA project



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.

Question is, do we want to avoid such sub-optimal result?

Wei.

> Jan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.