On Wed, Apr 12, 2023 at 3:57 PM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > > On 04/12/23 10:54, David Rientjes wrote: > > On Wed, 12 Apr 2023, Pasha Tatashin wrote: > > > > > HugeTLB pages have a struct page optimizations where struct pages for tail > > > pages are freed. However, when HugeTLB pages are destroyed, the memory for > > > struct pages (vmemmap) need to be allocated again. > > > > > > Currently, __GFP_NORETRY flag is used to allocate the memory for vmemmap, > > > but given that this flag makes very little effort to actually reclaim > > > memory the returning of huge pages back to the system can be problem. Lets > > > use __GFP_RETRY_MAYFAIL instead. This flag is also performs graceful > > > reclaim without causing ooms, but at least it may perform a few retries, > > > and will fail only when there is genuinely little amount of unused memory > > > in the system. > > > > > > > Thanks Pasha, this definitely makes sense. We want to free the hugetlb > > page back to the system so it would be a shame to have to strand it in the > > hugetlb pool because we can't allocate the tail pages (we want to free > > more memory than we're allocating). > > Agree. > > The hugetlb vmemmmap freeing series went through more than 20 revisions > before being merged. One issue with much discussion was the need to > allocate vmemmap pages when hugetlb pages were returned to buddy. > > It looks like the current set of GFP flags was suggested here: > https://lore.kernel.org/linux-mm/YC4ji+pMhtOs+KVM@xxxxxxxxxxxxxx/ > > Although, it was also mentioned that __GFP_RETRY_MAYFAIL could be used > instead of __GFP_NORETRY here: > https://lore.kernel.org/linux-mm/YCafit5ruRJ+SL8I@xxxxxxxxxxxxxx/ > > Adding Michal on Cc: since these were his suggestions. Thank you for the background Mike. I have sent the 2nd version, and added Michal into that patch. Pasha
