On Wed 01-04-20 15:22:58, Uladzislau Rezki wrote: > > > We call it from atomic context, so we can not sleep, also we do not have > > > any existing context coming from the caller. I see that GFP_ATOMIC is high-level > > > flag and is differ from __GFP_ATOMIC. It is defined as: > > > > > > #define GFP_ATOMIC (__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM) > > > > > > so basically we would like to have __GFP_KSWAPD_RECLAIM that is included in it, > > > because it will also help in case of high memory pressure and wake-up kswapd to > > > reclaim memory. > > > > > > We also can extract: > > > > > > __GFP_ATOMIC | __GFP_HIGH | __GFP_RETRY_MAYFAIL | __GFP_KSWAPD_RECLAIM > > > > > > but that is longer then > > > > > > GFP_ATMOC | __GFP_RETRY_MAYFAIL > > > > OK, if you are always in the atomic context then GFP_ATOMIC is > > sufficient. __GFP_RETRY_MAYFAIL will make no difference for allocations > > which do not reclaim (and thus not retry). Sorry this was not clear to > > me from the previous description. > > > Ahh. OK. Then adding __GFP_RETRY_MAYFAIL to GFP_ATOMIC will not make any effect. > > Thank you for your explanation! Welcome. I wish all those gfp flags were really clear but I fully understand that people who are not working with MM regurarly might find it confusing. Btw. have __GFP_RETRY_MAYFAIL is documented in gfp.h and it is documented as the reclaim modifier which should imply that it has no effect when the reclaim is not allowed which is the case for any non sleeping allocation. If that relation was not immediately obvious then I think we need to make it explicit. Would you find it useful? E.g. diff --git a/include/linux/gfp.h b/include/linux/gfp.h index e3ab1c0d9140..8f09cefdfa7b 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -127,6 +127,8 @@ struct vm_area_struct; * * Reclaim modifiers * ~~~~~~~~~~~~~~~~~ + * Please note that all the folloging flags are only applicable to sleepable + * allocations (e.g. %GFP_NOWAIT and %GFP_ATOMIC will ignore them). * * %__GFP_IO can start physical IO. * -- Michal Hocko SUSE Labs
