[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Sent patch to lkml late last week ([PATCH] xen/setup: Remap Xen Identity Mapped RAM). Will cc xen-devel on further correspondance.

-Matt

Jan



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.