On Tue 10-02-15 10:19:34, Johannes Weiner wrote:
[...]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8e20f9c2fa5a..f77c58ebbcfa 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2382,8 +2382,15 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order,
> if (high_zoneidx < ZONE_NORMAL)
> goto out;
> /* The OOM killer does not compensate for light reclaim */
> - if (!(gfp_mask & __GFP_FS))
> + if (!(gfp_mask & __GFP_FS)) {
> + /*
> + * XXX: Page reclaim didn't yield anything,
> + * and the OOM killer can't be invoked, but
> + * keep looping as per should_alloc_retry().
> + */
> + *did_some_progress = 1;
> goto out;
> + }
> /*
> * GFP_THISNODE contains __GFP_NORETRY and we never hit this.
> * Sanity check for bare calls of __GFP_THISNODE, not real OOM.
Although the side effect of 9879de7373fc (mm: page_alloc: embed OOM
killing naturally into allocation slowpath) is subtle and it would be
much better if it was documented in the changelog (I have missed that
too during review otherwise I would ask for that) I do not think this is
a change in a good direction. Hopelessly retrying at the time when the
reclaimm didn't help and OOM is not available is simply a bad(tm)
choice.
Besides that __GFP_WAIT callers should be prepared for the allocation
failure and should better cope with it. So no, I really hate something
like the above.
--
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>