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

[Matthew Rushton <mvrushton@gmail.com>]

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

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