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

[Matthew Rushton <mvrushton@gmail.com>]

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