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

[Tim Deegan <tim@xxxxxxx>]

At 13:05 -0400 on 11 Apr (1397217936), 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.

That's not quite what I meant to say.  I think that:
 (a) Making this change would be OK, as it should be harmless and 
     happens to help people running older linux kernels.  That comes
     with the caveats I mentioned: dom0 should not be relying on this
     and we (xen) reserve the right to change it later even if that makes
     unfixed linux dom0 slow again.
     We also shouldn't make this change on debug builds (to catch
     cases where a guest relies on the new behaviour for _correctness_).
 (b) The right thing to do is to fix linux so that it asks for
     contiguous memory in cases where that matters.  AFAICT that would
     involve allocating in larger areas than 1 page.
 (c) If for some reason the current hypercall API is not sufficient
     for dom0 to get what it wants, we should consider adding some new
     operation/flag/mode somewhere.  But since AFAIK there's already
     another path in linux that allocates contiguous DMA buffers
     for device drivers, presumably this isn't the case.

Cheers,

Tim.

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