Hi, this is a follow up for __GFP_REPEAT clean up merged into mmotm just recently [1]. The main motivation for the change is that the current implementation of __GFP_REPEAT is not very much useful. The documentation says: * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt * _might_ fail. This depends upon the particular VM implementation. It just fails to mention that this is true only for large (costly) high order which has been the case since the flag was introduced. A similar semantic would be really helpful for smal orders as well, though, because we have places where a failure with a specific fallback error handling is preferred to a potential endless loop inside the page allocator. The cleanup [1] dropped __GFP_REPEAT usage for low (!costly) order users so only those which might use larger orders have stayed. Let's rename the flag to something more verbose and use it for existing users. Semantic for those will not change. Then implement low (!costly) orders failure path which is hit after the page allocator is about to hit the oom killer path again. That means that the first OOM killer invocation and all the retries after then haven't helped to move on. This seems like a good indication that any further progress is highly unlikely. Xfs code already has an existing annotation for allocations which are allowed to fail and we can trivially map them to the new gfp flag because it will provide the semantic KM_MAYFAIL wants. I assume we will grow more users - e.g. GFP_USER sounds like it could use the flag by default. But I haven't explored this path properly yet. I am sending this as an RFC and would like to hear back about the approach. We have discussed this at LSF this year and there were different ideas how to achieve the semantic. I have decided to go __GFP_RETRY_HARD way because it nicely fits into the existing scheme where __GFP_NORETRY and __GFP_NOFAIL already modify the default behavior of the page allocator and the new flag would fit nicely between the two existing flags. The patch 1 is much more verbose about different modes of operation of the page allocator. Thanks --- [1] http://lkml.kernel.org/r/1464599699-30131-1-git-send-email-mhocko@xxxxxxxxxx -- 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>