> > > > > > 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. > * That would be definitely clear for me! -- Vlad Rezki
