From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Rushton Subject: Re: [RFC PATCH] page_alloc: use first half of higher order chunks when halving Date: Fri, 11 Apr 2014 13:28:45 -0700 Message-ID: <5348507D.50204@gmail.com> References: <20140331141500.GB3159@phenom.dumpdata.com> <533A31B7.8090608@gmail.com> <20140401104825.GA5342@localhost.localdomain> <20140401122223.GA62612@deinos.phlegethon.org> <533B5732.6050001@gmail.com> <533BDDF0020000780000489C@nat28.tlf.novell.com> <1396433179.8667.292.camel@kazak.uk.xensource.com> <533BFF7D02000078000049B8@nat28.tlf.novell.com> <1396434020.8667.300.camel@kazak.uk.xensource.com> <5345C7F2.5050005@gmail.com> <20140411170536.GA14755@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WYi4B-0007x0-HB for xen-devel@lists.xenproject.org; Fri, 11 Apr 2014 20:28:51 +0000 Received: by mail-pa0-f45.google.com with SMTP id kl14so5864026pab.32 for ; Fri, 11 Apr 2014 13:28:47 -0700 (PDT) In-Reply-To: <20140411170536.GA14755@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Keir Fraser , Ian Campbell , AndrewCooper , Tim Deegan , Jan Beulich , Matt Wilson , Matt Wilson , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org 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, wrote: >>>>> On Wed, 2014-04-02 at 08:52 +0100, Jan Beulich wrote: >>>>>>>>> On 02.04.14 at 02:17, 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@lists.xen.org >> http://lists.xen.org/xen-devel