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

[Matthew Rushton <mvrushton@xxxxxxxxx>]

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.
> > > > Jan

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