2020년 7월 8일 (수) 오전 4:00, Michal Hocko <mhocko@xxxxxxxxxx>님이 작성: > > On Tue 07-07-20 16:49:51, Vlastimil Babka wrote: > > On 7/7/20 9:44 AM, js1304@xxxxxxxxx wrote: > > > From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> > > > > > > There are some similar functions for migration target allocation. Since > > > there is no fundamental difference, it's better to keep just one rather > > > than keeping all variants. This patch implements base migration target > > > allocation function. In the following patches, variants will be converted > > > to use this function. > > > > > > Changes should be mechanical but there are some differences. First, Some > > > callers' nodemask is assgined to NULL since NULL nodemask will be > > > considered as all available nodes, that is, &node_states[N_MEMORY]. > > > Second, for hugetlb page allocation, gfp_mask is ORed since a user could > > > provide a gfp_mask from now on. > > > > I think that's wrong. See how htlb_alloc_mask() determines between > > GFP_HIGHUSER_MOVABLE and GFP_HIGHUSER, but then you OR it with __GFP_MOVABLE so > > it's always GFP_HIGHUSER_MOVABLE. Indeed. > Right you are! Not that it would make any real difference because only > migrateable hugetlb pages will get __GFP_MOVABLE and so we shouldn't > really end up here for !movable pages in the first place (not sure about > soft offlining at this moment). But yeah it would be simply better to > override gfp mask for hugetlb which we have been doing anyway. Override gfp mask doesn't work since some users will call this function with __GFP_THISNODE. I will use hugepage_movable_supported() here and clear __GFP_MOVABLE if needed. Thanks. Thanks.
