On Tue 07-07-20 16:44:43, Joonsoo Kim wrote: > From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> > > In mm/migrate.c, THP allocation for migration is called with the provided > gfp_mask | GFP_TRANSHUGE. This gfp_mask contains __GFP_RECLAIM and it > would be conflict with the intention of the GFP_TRANSHUGE. > > GFP_TRANSHUGE/GFP_TRANSHUGE_LIGHT is introduced to control the reclaim > behaviour by well defined manner since overhead of THP allocation is > quite large and the whole system could suffer from it. So, they deals > with __GFP_RECLAIM mask deliberately. If gfp_mask contains __GFP_RECLAIM > and uses gfp_mask | GFP_TRANSHUGE(_LIGHT) for THP allocation, it means > that it breaks the purpose of the GFP_TRANSHUGE(_LIGHT). GFP_TRANSHUGE* is not a carved in stone design. Their primary reason to exist is to control how hard to try for different allocation paths/configurations because their latency expectations might be largerly different. It is mostly the #PF path which aims to be as lightweight as possible I believe nobody simply considered migration to be very significant to even care. And I am still not sure it matters but I would tend to agree that a consistency here is probably a very minor plus. Your changelog is slightly misleading in that regard because it suggests that this is a real problem while it doesn't present any actual data. It would be really nice to make the effective change really stand out. We are only talking about __GFP_RECLAIM_KSWAPD here. So the only difference is that the migration won't wake up kswapd now. All that being said the changelog should be probably more explicit about the fact that this is solely done for consistency and be honest that the runtime effect is not really clear. This would help people reading it in future. -- Michal Hocko SUSE Labs
