All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Michal Hocko <mhocko@suse.cz>, Nikolay Borisov <kernel@kyup.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Chinner <david@fromorbit.com>,
	"Theodore Ts'o" <tytso@mit.edu>, Marian Marinov <mm@1h.com>,
	Hugh Dickins <hughd@google.com>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
Date: Wed, 01 Jul 2015 10:30:36 -0400	[thread overview]
Message-ID: <5593F98C.4010406@redhat.com> (raw)
In-Reply-To: <20150701133715.GA6287@dhcp22.suse.cz>

On 07/01/2015 09:37 AM, Michal Hocko wrote:

> Fix this issue by limiting the wait to reclaim triggered by __GFP_FS
> allocations to make sure we are not called from filesystem paths which
> might be doing exactly this kind of IO optimizations. The page fault
> path, which is the only path that triggers memcg oom killer since 3.12,
> shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature
> OOM killer issue which was originally addressed by the heuristic.
> 
> As per David Chinner the xfs is doing similar thing since 2.6.15 already
> so ext4 is not the only affected filesystem. Moreover he notes:
> : For example: IO completion might require unwritten extent conversion
> : which executes filesystem transactions and GFP_NOFS allocations. The
> : writeback flag on the pages can not be cleared until unwritten
> : extent conversion completes. Hence memory reclaim cannot wait on
> : page writeback to complete in GFP_NOFS context because it is not
> : safe to do so, memcg reclaim or otherwise.

I remember fixing something like this back in the 2.2
days. Funny how these bugs keep coming back.

> Cc: stable # 3.6+
> Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
> Reported-by: Nikolay Borisov <kernel@kyup.com>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>

Reviewed-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Michal Hocko <mhocko@suse.cz>, Nikolay Borisov <kernel@kyup.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Chinner <david@fromorbit.com>,
	"Theodore Ts'o" <tytso@mit.edu>, Marian Marinov <mm@1h.com>,
	Hugh Dickins <hughd@google.com>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
Date: Wed, 01 Jul 2015 10:30:36 -0400	[thread overview]
Message-ID: <5593F98C.4010406@redhat.com> (raw)
In-Reply-To: <20150701133715.GA6287@dhcp22.suse.cz>

On 07/01/2015 09:37 AM, Michal Hocko wrote:

> Fix this issue by limiting the wait to reclaim triggered by __GFP_FS
> allocations to make sure we are not called from filesystem paths which
> might be doing exactly this kind of IO optimizations. The page fault
> path, which is the only path that triggers memcg oom killer since 3.12,
> shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature
> OOM killer issue which was originally addressed by the heuristic.
> 
> As per David Chinner the xfs is doing similar thing since 2.6.15 already
> so ext4 is not the only affected filesystem. Moreover he notes:
> : For example: IO completion might require unwritten extent conversion
> : which executes filesystem transactions and GFP_NOFS allocations. The
> : writeback flag on the pages can not be cleared until unwritten
> : extent conversion completes. Hence memory reclaim cannot wait on
> : page writeback to complete in GFP_NOFS context because it is not
> : safe to do so, memcg reclaim or otherwise.

I remember fixing something like this back in the 2.2
days. Funny how these bugs keep coming back.

> Cc: stable # 3.6+
> Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
> Reported-by: Nikolay Borisov <kernel@kyup.com>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>

Reviewed-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed

  reply	other threads:[~2015-07-01 14:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 15:17 [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations Michal Hocko
2015-06-30 15:17 ` Michal Hocko
2015-06-30 15:17 ` Michal Hocko
2015-07-01  6:17 ` Michal Hocko
2015-07-01  6:17   ` Michal Hocko
2015-07-01 13:37   ` Michal Hocko
2015-07-01 13:37     ` Michal Hocko
2015-07-01 13:37     ` Michal Hocko
2015-07-01 14:30     ` Rik van Riel [this message]
2015-07-01 14:30       ` Rik van Riel
2015-07-02 14:25     ` Theodore Ts'o
2015-07-02 14:25       ` Theodore Ts'o
2015-07-02 15:13       ` Michal Hocko
2015-07-02 15:13         ` Michal Hocko
2015-07-02 15:13         ` Michal Hocko
2015-08-04  6:32         ` Hugh Dickins
2015-08-04  6:32           ` Hugh Dickins
2015-08-04  9:51           ` Michal Hocko
2015-08-04  9:51             ` Michal Hocko
2015-08-04 21:32             ` Hugh Dickins
2015-08-04 21:32               ` Hugh Dickins
2015-08-04 21:36             ` Hugh Dickins
2015-08-04 21:36               ` Hugh Dickins
2015-08-07  7:52           ` Nikolay Borisov
2015-08-07  7:52             ` Nikolay Borisov
2015-08-13  2:13             ` Hugh Dickins
2015-08-13  2:13               ` Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5593F98C.4010406@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kernel@kyup.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=mm@1h.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.