On Thu 05-01-17 19:50:23, Tetsuo Handa wrote: [...] > Anyway, I suggest merging description update shown below into this series and > getting confirmation from all existing __GFP_NOFAIL users. If all existing > __GFP_NOFAIL users are OK with this series (in other words, informed the risk > caused by this series), I'm also OK with this series. > > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -135,16 +135,24 @@ > * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt > * _might_ fail. This depends upon the particular VM implementation. > * > - * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller > - * cannot handle allocation failures. New users should be evaluated carefully > - * (and the flag should be used only when there is no reasonable failure > - * policy) but it is definitely preferable to use the flag rather than > - * opencode endless loop around allocator. > - * > - * __GFP_NORETRY: The VM implementation must not retry indefinitely and will > - * return NULL when direct reclaim and memory compaction have failed to allow > - * the allocation to succeed. The OOM killer is not called with the current > - * implementation. > + * __GFP_NOFAIL: The VM implementation must not give up even after direct > + * reclaim and memory compaction have failed to allow the allocation to > + * succeed. Note that since the OOM killer is not called with the current > + * implementation when direct reclaim and memory compaction have failed to > + * allow the allocation to succeed unless __GFP_FS is also used (and some > + * other conditions are met), e.g. GFP_NOFS | __GFP_NOFAIL allocation has > + * possibility of lockup. To reduce the possibility of lockup, __GFP_HIGH is > + * implicitly granted by the current implementation if __GFP_NOFAIL is used. > + * New users of __GFP_NOFAIL should be evaluated carefully (and __GFP_NOFAIL > + * should be used only when there is no reasonable failure policy) but it is > + * definitely preferable to use __GFP_NOFAIL rather than opencode endless > + * loop around allocator, for a stall detection check inside allocator will > + * likely be able to emit possible lockup warnings unless __GFP_NOWARN is > + * also used. This is both wrong and unnecessarily describing implementation details. Non-failing allocation which must not give up can lockup pretty much by definition. IMHO the current description is sufficient. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>