On Fri 26-06-20 13:49:15, Joonsoo Kim wrote: > 2020년 6월 25일 (목) 오후 8:54, Michal Hocko <mhocko@xxxxxxxxxx>님이 작성: > > > > On Tue 23-06-20 15:13:44, Joonsoo Kim wrote: > > > From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> > > > > > > new_non_cma_page() in gup.c which try to allocate migration target page > > > requires to allocate the new page that is not on the CMA area. > > > new_non_cma_page() implements it by removing __GFP_MOVABLE flag. This way > > > works well for THP page or normal page but not for hugetlb page. > > > > Could you explain why? I mean why cannot you simply remove __GFP_MOVABLE > > flag when calling alloc_huge_page_nodemask and check for it in dequeue > > path? > > If we remove __GFP_MOVABLE when calling alloc_huge_page_nodemask, we cannot > use the page in ZONE_MOVABLE on dequeing. > > __GFP_MOVABLE is not only used for CMA selector but also used for zone > selector. If we clear it, we cannot use the page in the ZONE_MOVABLE > even if it's not CMA pages. For THP page or normal page allocation, > there is no way to avoid this weakness without introducing another > flag or argument. For me, introducing another flag or argument for > these functions looks over-engineering so I don't change them and > leave them as they are (removing __GFP_MOVABLE). > > But, for alloc_huge_page_nodemask(), introducing a new argument > doesn't seem to be a problem since it is not a general function but > just a migration target allocation function. I really do not see why hugetlb and only the dequeing part should be special. This just leads to a confusion. From the code point of view it makes perfect sense to opt out CMA regions for !__GFP_MOVABLE when dequeing. So I would rather see a consistent behavior than a special case deep in the hugetlb allocator layer. -- Michal Hocko SUSE Labs
