Re: [PATCH mm-unstable v2] mm/page_alloc: keep track of free highatomic

[Vlastimil Babka]

On 10/27/24 21:51, Yu Zhao wrote:
> On Sun, Oct 27, 2024 at 2:36 PM Vlastimil Babka <vbabka@xxxxxxx> wrote:
>>
>> On 10/27/24 21:17, Yu Zhao wrote:
>> > On Sun, Oct 27, 2024 at 1:53 PM Vlastimil Babka <vbabka@xxxxxxx> wrote:
>> >>
>>
>> For example:
>>
>> - a page is on pcplist in MIGRATE_MOVABLE list
>> - we reserve its pageblock as highatomic, which does nothing to the page on
>> the pcplist
>> - page above is flushed from pcplist to zone freelist, but it remembers it
>> was MIGRATE_MOVABLE, merges with another buddy/buddies from the
>> now-highatomic list, the resulting order-X page ends up on the movable
>> freelist despite being in highatomic pageblock. The counter of free
>> highatomic is now wrong wrt the freelist reality
> 
> This is the part I don't follow: how is it wrong w.r.t. the freelist
> reality? The new nr_free_highatomic should reflect how many pages are
> exactly on free_list[MIGRATE_HIGHATOMIC], because it's updated
> accordingly.

You'd have to try implementing your change in the kernel without that
migratetype hygiene series, and see how it would either not work, or you'd
end up implementing the series as part of that.

> (My current understanding is that, in this case, the reservation
> itself is messed up, i.e., under-reserved.)
> 
>> The series has addressed various scenarios like that, where page can end up
>> on the wrong freelist.