Re: [Xen-devel] [XEN PATCH v2 1/2] Check zone before merging adjacent blocks in heap

[Stewart Hildebrand <Stewart.Hildebrand@xxxxxxxxxxxxxxx>]

On Tuesday, February 4, 2020 10:22 AM, Jan Beulich wrote:
>On 04.02.2020 16:14, Stewart Hildebrand wrote:
>> From: Jeff Kubascik <jeff.kubascik@xxxxxxxxxxxxxxx>
>>
>> The Xen heap is split up into nodes and zones. Each node + zone is
>> managed as a separate pool of memory.
>>
>> When returning pages to the heap, free_heap_pages will check adjacent
>> blocks to see if they can be combined into a larger block. However, the
>> zone of the adjacent block is not checked. This results in blocks that
>> migrate from one zone to another.
>>
>> When a block migrates to the adjacent zone, the avail counters for the
>> old and new node + zone is not updated accordingly. The avail counter
>> is used when allocating pages to determine whether to skip over a zone.
>> With this behavior, it is possible for free pages to collect in a zone
>> with the avail counter smaller than the actual page count, resulting
>> in free pages that are not allocable.
>
>"When a block migrates" - fine. But is this situation possible to
>occur, without "xen/page_alloc: Keep away MFN 0 from the buddy
>allocator" reverted?

No, not as far as I'm aware, though I have not studied this code in detail so I 
don't feel fully confident in my "no".

> If not, there's no bug, no need for a change,
>and even less so ...
>
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -1462,6 +1462,7 @@ static void free_heap_pages(
>>              if ( !mfn_valid(page_to_mfn(predecessor)) ||
>>                   !page_state_is(predecessor, free) ||
>>                   (PFN_ORDER(predecessor) != order) ||
>> +                 (page_to_zone(predecessor) != zone) ||
>>                   (phys_to_nid(page_to_maddr(predecessor)) != node) )
>>                  break;
>>
>> @@ -1485,6 +1486,7 @@ static void free_heap_pages(
>>              if ( !mfn_valid(page_to_mfn(successor)) ||
>>                   !page_state_is(successor, free) ||
>>                   (PFN_ORDER(successor) != order) ||
>> +                 (page_to_zone(successor) != zone) ||
>>                   (phys_to_nid(page_to_maddr(successor)) != node) )
>>                  break;
>
>... for one that slows down many free operations, even if just
>slightly. IOW afaict either the change is not needed, or its
>description needs updating.

Right. An alternative that wouldn't potentially slow things down in production 
builds would be to apply the ASSERT from patch 2. I don't have any performance 
metrics regarding exactly how much of a performance hit this would incur.

Stew

>
>Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel