[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 04/11/14 10:05, Konrad Rzeszutek Wilk wrote:
On Wed, Apr 09, 2014 at 03:21:38PM -0700, Matthew Rushton wrote:
On 04/02/14 03:20, Ian Campbell wrote:
On Wed, 2014-04-02 at 11:15 +0100, Jan Beulich wrote:
On 02.04.14 at 12:06, <Ian.Campbell@xxxxxxxxxx> wrote:
On Wed, 2014-04-02 at 08:52 +0100, Jan Beulich wrote:
On 02.04.14 at 02:17, <mvrushton@xxxxxxxxx> wrote:
On 04/01/14 05:22, Tim Deegan wrote:
As long as we don't also change the default allocation order in
Xen. :)  In general, linux shouldn't rely on the order that Xen
allocates memory, as that might change later.  If the current API
can't do what's needed, maybe we can add another allocator
hypercall or flag?
Agree on not relying on the order in the long run. A new hypercall or
flag seems like overkill right now. The question for me comes down to my
proposed change which is more simple and solves the short term problem
or investing time in reworking the Linux code to make large allocations.
I think it has become pretty clear by now that we'd rather not alter
the hypervisor allocator for a purpose like this.
OK understood see below.

Does it even actually solve the problem? It seems like it is just
deferring it until sufficient fragmentation has occurred in the system.
All its really done is make the eventual issue much harder to debug.
Wasn't this largely for Dom0 (in which case fragmentation shouldn't
matter yet)?
Dom0 ballooning breaks any assumptions you might make about relying on
early allocations.
I think you're missing the point. I'm not arguing that this change
is a general purpose solution to guarantee that dom0 is contiguous.
Fragmentation can exist even if dom0 asks for larger allocations
like it should (which the balloon driver does I believe). What the
change does do is solve a real problem in the current Linux PCI
remapping implementation which happens during dom0 intialization. If
the allocation strategy is arbitrary why not make the proposed
hypervisor change to make existing Linux implementations behave
better and in addition fix the problem in Linux so moving forward
things are safe?
I think Tim was OK with that - as long as it was based on a flag - meaning
when we do the increase_reservation call we use an extra flag
to ask for contingous PFNs.

OK the extra flag feels a little dirty to me but it would solve the problem. What are your thoughts on changing Linux to make higher order allocations or more minimally adding a boot parameter to not remap the memory at all for those that care about performance? I know the Linux code is already fairly complex and your preference was not to make it worse.

Ian.


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


_______________________________________________
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®.