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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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@oracle.com> 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@oracle.com>
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!?).


> 
> >>Jan
> >>
>