Re: [Xen-devel] [RFC PATCH] page_alloc: use first half of higher order chunks when halving

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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, <konrad.wilk@xxxxxxxxxx> 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 <konrad.wilk@xxxxxxxxxx>
> >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!
> 
> >>>>Jan
> >>>>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel