From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: RFC: vNUMA project Date: Wed, 12 Nov 2014 14:29:56 +0000 Message-ID: <54636EE4.7030001@citrix.com> References: <20141111173606.GC21312@zion.uk.xensource.com> <54624F6A.40002@citrix.com> <546337D50200007800046B2F@mail.emea.novell.com> <20141112134530.GA31665@zion.uk.xensource.com> <546379050200007800046D6A@mail.emea.novell.com> <20141112142705.GB31665@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141112142705.GB31665@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , Jan Beulich Cc: Dario Faggioli , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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, wrote: >>> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote: >>>>>>> On 11.11.14 at 19:03, 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