xfs
[Top] [All Lists]

Re: How to handle TIF_MEMDIE stalls?

To: Johannes Weiner <hannes@xxxxxxxxxxx>
Subject: Re: How to handle TIF_MEMDIE stalls?
From: David Rientjes <rientjes@xxxxxxxxxx>
Date: Mon, 23 Feb 2015 13:33:51 -0800 (PST)
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Theodore Ts'o <tytso@xxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>, mhocko@xxxxxxx, dchinner@xxxxxxxxxx, linux-mm@xxxxxxxxx, oleg@xxxxxxxxxx, mgorman@xxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=CbCLDBRBvwfsBDzA0A68GF8Zm/3CNE+C09zMYXaBzJE=; b=eWR1zUtL8fgdgI6dRqNYmeAyWtPYx8Nvpqh/4cHCN8ZX/k9Cw+NNW9AUV4VLhj7XVG QKfrlz+7vlhKjr8XiIXbKImKy0wFoHJRKrj7Jpphsbrc8okfabKbDWdfp+ZBVWM5OVFp ug8ebXSVGZyv1y/tQrhh7tHpu1RJmLU+sAiku6X4BPXKtEmI5JS3j65N0NzdA1YYwkim /onHES41Wb2Nks/yKdzbRN7NUs0brKs58Hj4oI/0R5+GLCm8C1Pr1fYouRcGR+gL5hXJ bhtQPnSJC3Uq7yQTlv1sZwJnB0lStzKy58POB90somoMQe0a9S/plbIcGFf+wtJwhviz I0aA==
In-reply-to: <20150222002058.GB25079@xxxxxxxxxxxxxxxxxxxxxx>
References: <201502172123.JIE35470.QOLMVOFJSHOFFt@xxxxxxxxxxxxxxxxxxx> <20150217125315.GA14287@xxxxxxxxxxxxxxxxxxxxxx> <20150217225430.GJ4251@dastard> <20150219102431.GA15569@xxxxxxxxxxxxxxxxxxxxxx> <20150219225217.GY12722@dastard> <201502201936.HBH34799.SOLFFFQtHOMOJV@xxxxxxxxxxxxxxxxxxx> <20150220231511.GH12722@dastard> <20150221032000.GC7922@xxxxxxxxx> <20150221011907.2d26c979.akpm@xxxxxxxxxxxxxxxxxxxx> <20150222002058.GB25079@xxxxxxxxxxxxxxxxxxxxxx>
User-agent: Alpine 2.10 (DEB 1266 2009-07-14)
On Sat, 21 Feb 2015, Johannes Weiner wrote:

> From: Johannes Weiner <hannes@xxxxxxxxxxx>
> 
> mm: page_alloc: revert inadvertent !__GFP_FS retry behavior change
> 
> Historically, !__GFP_FS allocations were not allowed to invoke the OOM
> killer once reclaim had failed, but nevertheless kept looping in the
> allocator.  9879de7373fc ("mm: page_alloc: embed OOM killing naturally
> into allocation slowpath"), which should have been a simple cleanup
> patch, accidentally changed the behavior to aborting the allocation at
> that point.  This creates problems with filesystem callers (?) that
> currently rely on the allocator waiting for other tasks to intervene.
> 
> Revert the behavior as it shouldn't have been changed as part of a
> cleanup patch.
> 
> Fixes: 9879de7373fc ("mm: page_alloc: embed OOM killing naturally into 
> allocation slowpath")
> Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>

Cc: stable@xxxxxxxxxxxxxxx [3.19]
Acked-by: David Rientjes <rientjes@xxxxxxxxxx>

<Prev in Thread] Current Thread [Next in Thread>