Re: [PATCH v17 1/9] mm: Adjust shuffle code to allow for future coalescing

[Alexander Duyck <alexander.duyck@gmail.com>]

Hi Bala,

There was a similar effort several months ago that was trying to do
this in conjunction with pre-zeroing of pages. I suspect if you wanted
to you could probably pick up some of their patch set and work with
that. It can be found at:
https://www.spinics.net/lists/linux-mm/msg239735.html

Thanks.

- Alex

On Tue, Mar 9, 2021 at 12:13 AM Bodeddula, Balasubramaniam
<bodeddub@amazon.com> wrote:
>
> Hi Alexander,
>
>
>
> My team was evaluating FPR and observed that these patches don’t report memory for deallocated hugeapages directly and need to cycle through buddy allocator. For example, say we need to allocate a maximum of 12 * 1G hugepages (by setting nr_hugepages), use 8 * 1G hugepages, and then deallocate 4 * 1G hugepages. Unlike regular 4K pages, this 4G worth of memory will not be reported until we set nr_hugepages to 8 (wait sometime(?) for FPR to do its work) and set it back again to 12. While this works fine in theory, in practice,  setting nr_hugepages to 12 could fail too due to fragmentation (this could depend on other processes memory usage behavior).
>
>
>
> If FPR could report this free memory without cycling through buddy allocator, it makes the solution more robust. I am looking for advice on how feasible this approach is and what would be the effort for building this functionality. In general, if there are other thoughts on how we can address this, please do let me know.
>
>
>
> Thanks,
>
> bala