From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC 1/2] xen/mm: Clarify the granularity for each Frame Number Date: Wed, 12 Aug 2015 13:57:41 +0100 Message-ID: <55CB42C5.2030307@citrix.com> References: <1438774133-1564-1-git-send-email-julien.grall@citrix.com> <1438774133-1564-2-git-send-email-julien.grall@citrix.com> <55C1F617.8090208@citrix.com> <55C2034F.9070508@citrix.com> <55C20595.8030502@citrix.com> <55C20D2D.1050806@citrix.com> <55CB0F000200007800099F11@prv-mh.provo.novell.com> <55CB1899.802@citrix.com> <55CB3D2A020000780009A132@prv-mh.provo.novell.com> <55CB2A52.4080704@citrix.com> <55CB511F020000780009A1F6@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZPVnI-0002SC-HT for xen-devel@lists.xenproject.org; Wed, 12 Aug 2015 13:10:12 +0000 In-Reply-To: <55CB511F020000780009A1F6@prv-mh.provo.novell.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: Jan Beulich Cc: Wei.Liu2@citrix.com, ian.campbell@citrix.com, Stefano Stabellini , Andrew Cooper , Ian Jackson , TimDeegan , stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org, Keir Fraser List-Id: xen-devel@lists.xenproject.org On 12/08/15 12:58, Jan Beulich wrote: >>>> On 12.08.15 at 13:13, wrote: >> On 12/08/15 11:33, Jan Beulich wrote: >>>>>> On 12.08.15 at 11:57, wrote: >>>> On 12/08/2015 08:16, Jan Beulich wrote: >>>>>>>> On 05.08.15 at 15:18, wrote: >>>>>> When the backend is 64K, it will map the foreign 4K at the top of a 64K >>>>>> page. It's a waste of memory, but it's easier to implement and it's >>>>>> still and improvement compare to have Linux crashing at boot. >>>>> >>>>> Waste of memory? You're only mapping an existing chunk of memory. >>>>> DYM waste of address space? >>>> >>>> No, I really meant waste of memory. The current grant API in Linux is >>>> allocating one Linux Page per grant. Although the grant is always 4K, so >>>> we won't be able to make use of the 60K for anything as long as we use >>>> this page for a grant. >>>> >>>> So if the grant is pre-allocated (such as for PV block), we won't be >>>> able use nr_grant * 60KB memory. >>> >>> I still don't follow - grant mappings ought to be done into ballooned >>> (i.e. empty) pages, i.e. no memory would get wasted unless there >>> are too few balloon pages available. >> >> Everything balloon out is less memory that can be used by Linux. If we >> are only using 1/15 of the balloon out page that a huge waste of memory >> for me. > > I still don't get it: A ballooned page does not represent any memory > (and at least on x86 iirc we start PV domains with 8Mb sort-of- > pre-ballooned space). Where is the loss you're talking about coming > from? Or, wait - you don't have PoD (yet) on ARM, so you have no > choice. I'm not sure how PoD would affect the problem here... An ARM guest can be considered as x86 HVM guest + PV drivers. At domain creation, all the RAM is allocated for this domain. Furthermore we have no memory hotplug support, so we would steal RAM page every time we have to balloon out a page. Regards, -- Julien Grall