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 <[email protected]> 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
