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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Apr 11, 2014 at 01:28:45PM -0700, Matthew Rushton wrote:
> 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

Oh, so just leave it ballooned down? I presume you can get the same
exact behavior if you have your dom0_mem=max:X value tweaked just
right? And your E820 does not look like swiss cheese.


> 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