From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC PATCH] page_alloc: use first half of higher order chunks when halving Date: Fri, 11 Apr 2014 13:05:36 -0400 Message-ID: <20140411170536.GA14755@phenom.dumpdata.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WYeuC-0004iK-Dq for xen-devel@lists.xenproject.org; Fri, 11 Apr 2014 17:06:20 +0000 Content-Disposition: inline In-Reply-To: <5345C7F2.5050005@gmail.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: Matthew Rushton 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 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. > > >Ian. > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel