On 1/15/21 2:16 AM, Oscar Salvador wrote: > On Mon, Jan 11, 2021 at 01:01:52PM -0800, Mike Kravetz wrote: >> Use new hugetlb specific flag HPageTempSurplus to replace the >> PageHugeTemporary() interfaces. >> >> Signed-off-by: Mike Kravetz <[email protected]> >> --- >> mm/hugetlb.c | 38 +++++++++----------------------------- >> 1 file changed, 9 insertions(+), 29 deletions(-) >> >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index 34ce82f4823c..949e1f987319 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -58,6 +58,7 @@ static unsigned long hugetlb_cma_size __initdata; >> enum htlb_page_flags { >> HPAGE_RestoreReserve = 0, >> HPAGE_Migratable, >> + HPAGE_TempSurplus, >> }; >> >> /* >> @@ -99,6 +100,7 @@ void ClearHPage##flname(struct page *page) \ >> >> HPAGEFLAG(RestoreReserve) >> EXT_HPAGEFLAG(Migratable) >> +HPAGEFLAG(TempSurplus) > > Would HPAGE_Temporary/Temporary not be a better fit?
Yes it would. > The point about current PageHugeTemporary is that these pages are temporary as > they do not belong to the pool and will vanish once the last reference gets > drop. > We do not really care that much about the surplus part? > > Besides, alloc_migrate_huge_page seems to not want to thread these pages as > surplus. > All correct, not sure why I was thinking 'surplus' when naming the flag. > Also, I would add a comment either next to each flag or above > the enum htlb_page_flags (probably the latter) with a brief explanation > of each flag. Will do. -- Mike Kravetz > Besides that, it looks fine to me. > Here I do not see the same problem in > stripping the PageHuge check in PageHugeTemporary, as I did in previous patch, > because all callers of it make sure they operate on a hugetlb page. >
