From: Michal Hocko <mhocko@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Dave Chinner <david@fromorbit.com>
Subject: Re: implicit AOP_FLAG_NOFS for grab_cache_page_write_begin
Date: Fri, 17 Apr 2020 10:00:03 +0200 [thread overview]
Message-ID: <20200417080003.GH26707@dhcp22.suse.cz> (raw)
In-Reply-To: <20200417072931.GA20822@infradead.org>
On Fri 17-04-20 00:29:31, Christoph Hellwig wrote:
> On Wed, Apr 15, 2020 at 09:02:28AM +0200, Michal Hocko wrote:
> > Hi,
> > I have just received a bug report about memcg OOM [1]. The underlying
> > issue is memcg specific but the stack trace made me look at the write(2)
> > patch and I have noticed that iomap_write_begin enforces AOP_FLAG_NOFS
> > which means that all the page cache that has to be allocated is
> > GFP_NOFS. What is the reason for this? Do all filesystems really need
> > the reclaim protection? I was hoping that those filesystems which really
> > need NOFS context would be using the scope API
> > (memalloc_nofs_{save,restore}.
>
> This comes from the historic XFS code, and this commit from Dave
> in particular:
>
> commit aea1b9532143218f8599ecedbbd6bfbf812385e1
> Author: Dave Chinner <dchinner@redhat.com>
> Date: Tue Jul 20 17:54:12 2010 +1000
>
> xfs: use GFP_NOFS for page cache allocation
>
> Avoid a lockdep warning by preventing page cache allocation from
> recursing back into the filesystem during memory reclaim.
Thanks for digging this up! The changelog is not really clear whether
NOFS is to avoid false possitive lockup warnings or real ones. If the
former then we have grown __GFP_NOLOCKDEP flag to workaround the problem
if the later then can we use memalloc_nofs_{save,restore} in the xfs
specific code please?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-04-17 8:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 7:02 implicit AOP_FLAG_NOFS for grab_cache_page_write_begin Michal Hocko
2020-04-17 7:29 ` Christoph Hellwig
2020-04-17 8:00 ` Michal Hocko [this message]
2020-04-17 8:06 ` Christoph Hellwig
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=20200417080003.GH26707@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).