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, 04 Jun 2014 15:25:37 -0700 Message-ID: <538F9CE1.4000108@gmail.com> References: <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> <536ABEBE.40101@gmail.com> <20140514150623.GA4732@phenom.dumpdata.com> <537BAC81.1030101@gmail.com> <20140523190043.GD9321@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.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WsJcu-0003Ig-7u for xen-devel@lists.xenproject.org; Wed, 04 Jun 2014 22:25:44 +0000 Received: by mail-pd0-f180.google.com with SMTP id y13so134814pdi.25 for ; Wed, 04 Jun 2014 15:25:40 -0700 (PDT) In-Reply-To: <20140523190043.GD9321@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 Cc: Keir Fraser , Ian Campbell , AndrewCooper , Tim Deegan , mrushton@amazon.com, msw@amazon.com, Matt Wilson , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 05/23/14 12:00, Konrad Rzeszutek Wilk wrote: > On Tue, May 20, 2014 at 12:26:57PM -0700, Matthew Rushton wrote: >> On 05/14/14 08:06, Konrad Rzeszutek Wilk wrote: >>> On Wed, May 07, 2014 at 04:16:14PM -0700, Matthew Rushton wrote: >>>> 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! >>>> I have a first pass at this. Just need to test it and should have something >>>> ready sometime next week or so. >>> Daniel pointed me to this commit: >>> ommit 2e2fb75475c2fc74c98100f1468c8195fee49f3b >>> Author: Konrad Rzeszutek Wilk >>> Date: Fri Apr 6 10:07:11 2012 -0400 >>> >>> xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM >>> .. >>> The other solution (that did not work) was to transplant the MFN in >>> the P2M tree - the ones that were going to be freed were put in >>> the E820_RAM regions past the nr_pages. But the modifications to the >>> M2P array (the other side of creating PTEs) were not carried away. >>> As the hypervisor is the only one capable of modifying that and the >>> only two hypercalls that would do this are: the update_va_mapping >>> (which won't work, as during initial bootup only PFNs up to nr_pages >>> are mapped in the guest) or via the populate hypercall. >>> >>> Where I talk about the 'update_va_mapping' - and I seem to think >>> that it would not work (due to the nr_pages limit). I don't actually >>> remember the details - so I might have been incorrect (hopefully!?). >>> >> Ok I finally have something I'm happy with using the mmu_update hypercall >> and placing things in the existing E820 map. I don't think the >> update_va_mapping hypercall is necessary. It ended up being a little more >> complicated than I originally thought to handle not allocating additional >> p2m leaf nodes. I'm going on vacation here shortly and can post it when I >> get back. > Enjoy the vacation and I am looking forward to seeing the patches when you > come back! > > Thank you! Sent patch to lkml late last week ([PATCH] xen/setup: Remap Xen Identity Mapped RAM). Will cc xen-devel on further correspondance. -Matt >>>>>> Jan >>>>>>