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

[Matthew Rushton <mvrushton@gmail.com>]

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@citrix.com> wrote:
>>>>> On Wed, 2014-04-02 at 08:52 +0100, Jan Beulich wrote:
>>>>>>>>> On 02.04.14 at 02:17, <mvrushton@gmail.com> 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