[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |