From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Rushton Subject: Re: [RFC PATCH] page_alloc: use first half of higher order chunks when halving Date: Wed, 16 Apr 2014 18:34:08 -0700 Message-ID: <534F2F90.7090305@gmail.com> References: <533BDDF0020000780000489C@nat28.tlf.novell.com> <1396433179.8667.292.camel@kazak.uk.xensource.com> <533BFF7D02000078000049B8@nat28.tlf.novell.com> <1396434020.8667.300.camel@kazak.uk.xensource.com> <5345C7F2.5050005@gmail.com> <20140411170536.GA14755@phenom.dumpdata.com> <20140413213220.GG99209@deinos.phlegethon.org> <534BBDB602000078000084CA@nat28.tlf.novell.com> <20140414144017.GB23371@phenom.dumpdata.com> <534C1C37020000780000891D@nat28.tlf.novell.com> <20140416141550.GB8403@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" 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 1WabDT-00079m-Fq for xen-devel@lists.xenproject.org; Thu, 17 Apr 2014 01:34:15 +0000 Received: by mail-pa0-f42.google.com with SMTP id fb1so11612565pad.15 for ; Wed, 16 Apr 2014 18:34:12 -0700 (PDT) In-Reply-To: <20140416141550.GB8403@phenom.dumpdata.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: Konrad Rzeszutek Wilk , msw@amazon.com Cc: Keir Fraser , Ian Campbell , AndrewCooper , Tim Deegan , Matt Wilson , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 04/16/14 07:15, Konrad Rzeszutek Wilk wrote: > On Mon, Apr 14, 2014 at 04:34:47PM +0100, Jan Beulich wrote: >>>>> On 14.04.14 at 16:40, wrote: >>> That was OK, but the M2P lookup table was not too thrilled with this. >>> Perhaps I should have used another hypercall to re-arrange the M2P? >>> I think I did try 'XENMEM_exchange' but that is not the right call either. >> Yeah, that's allocating new pages in exchange for your old ones. Not >> really what you want. >> >>> Perhaps I should use XENMEM_remove_from_physmap/XENMEM_add_to_physmap >>> combo ? >> A pair of MMU_MACHPHYS_UPDATE operations would seem to be the >> right way of doing this (along with respective kernel internal accounting >> like set_phys_to_machine(), and perhaps a pair of update_va_mapping >> operations if the 1:1 map is already in place at that time, and you care >> about which page contents appears at which virtual address). > OK. > > Matt & Matthew - my plate is quite filled and I fear that in the next three > weeks there is not going to be much time to code up a prototype. > > Would either one of you be willing to take a crack at this? It would > be neat as we could remove a lot of the balloon increase/decrease code > in arch/x86/xen/setup.c. > > Thanks! Yeah sure. It won't be immediatly but I should be able to do that. >> Jan >>