Re: [PATCH 05/12] xen: introduce reserve_heap_pages

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 30 Apr 2020, Jan Beulich wrote:
> On 30.04.2020 00:46, Stefano Stabellini wrote:
> > On Fri, 17 Apr 2020, Jan Beulich wrote:
> >> On 15.04.2020 03:02, Stefano Stabellini wrote:
> >>> Introduce a function named reserve_heap_pages (similar to
> >>> alloc_heap_pages) that allocates a requested memory range. Call
> >>> __alloc_heap_pages for the implementation.
> >>>
> >>> Change __alloc_heap_pages so that the original page doesn't get
> >>> modified, giving back unneeded memory top to bottom rather than bottom
> >>> to top.
> >>
> >> While it may be less of a problem within a zone, doing so is
> >> against our general "return high pages first" policy.
> > 
> > Is this something you'd be OK with anyway?
> 
> As a last resort, maybe. But it really depends on why it needs to be
> this way.
> 
> > If not, do you have a suggestion on how to do it better? I couldn't find
> > a nice way to do it without code duplication, or a big nasty 'if' in the
> > middle of the function.
> 
> I'd first need to understand the problem to solve.

OK, I'll make an example.

reserve_heap_pages wants to reserve the range 0x10000000 - 0x20000000.

reserve_heap_pages get the struct page_info for 0x10000000 and calls
alloc_pages_from_buddy to allocate an order of 28.

alloc_pages_from_buddy realizes that the free memory area starting from
0x10000000 is actually of order 30, even larger than the requested order
of 28. The free area is 0x10000000 - 0x50000000.

alloc_pages_from_buddy instead of just allocating an order of 28
starting from 0x10000000, it would allocate the "top" order of 28 in the
free area. So it would allocate: 0x40000000 - 0x50000000, returning
0x40000000.

Of course, this doesn't work for reserve_heap_pages.


This patch changes the behavior of alloc_pages_from_buddy so that in a
situation like the above, it would return 0x10000000 - 0x20000000
(leaving the rest of the free area unallocated.)