[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:29:56PM +0000, David Vrabel wrote:
> 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.
> 

Fair enough.

So what's the "usual technique" in Linux to make sure if a specific
Xen feature is present?

Jan, is it suitable to use a XENFEAT_* bit for this?

Wei.

> David

_______________________________________________
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®.