From: Jonathan Corbet <corbet@lwn.net>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-doc@vger.kernel.org, Michal Hocko <mhocko@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-xfs@vger.kernel.org, dm-devel@redhat.com,
Mikulas Patocka <mpatocka@redhat.com>,
Jens Axboe <axboe@kernel.dk>, NeilBrown <neilb@suse.de>
Subject: Re: [willy@infradead.org: Re: [PATCH 6/6] mm: Add memalloc_nowait]
Date: Wed, 1 Jul 2020 15:35:32 -0600 [thread overview]
Message-ID: <20200701153532.63d49389@lwn.net> (raw)
In-Reply-To: <20200701041316.GA7193@casper.infradead.org>
On Wed, 1 Jul 2020 05:13:16 +0100
Matthew Wilcox <willy@infradead.org> wrote:
> > > -It turned out though that above approach has led to
> > > -abuses when the restricted gfp mask is used "just in case" without a
> > > -deeper consideration which leads to problems because an excessive use
> > > -of GFP_NOFS/GFP_NOIO can lead to memory over-reclaim or other memory
> > > -reclaim issues.
> >
> > I believe this is an important part because it shows that new people
> > coming to the existing code shouldn't take it as correct and rather
> > question it. Also having a clear indication that overuse is causing real
> > problems that might be not immediately visible to subsystems outside of
> > MM.
>
> It seemed to say a lot of the same things as this paragraph:
>
> +You may notice that quite a few allocations in the existing code specify
> +``GFP_NOIO`` or ``GFP_NOFS``. Historically, they were used to prevent
> +recursion deadlocks caused by direct memory reclaim calling back into
> +the FS or IO paths and blocking on already held resources. Since 4.12
> +the preferred way to address this issue is to use the new scope APIs
> +described below.
>
> Since this is in core-api/ rather than vm/, I felt that discussion of
> the problems that it causes to the mm was a bit too much detail for the
> people who would be reading this document. Maybe I could move that
> information into a new Documentation/vm/reclaim.rst file?
>
> Let's see if Our Grumpy Editor has time to give us his advice on this.
So I don't have time to really dig into the context here...but I can try.
Certainly there needs to be enough information to get people to think
about using those flags, even if they are copypasting other code that
does. I'd be inclined to err on the side of including too much
information rather than too little. Of course, you could make the
reclaim.rst file, then cross-link it if the result seems better.
In other words, do all of the above :)
jon
prev parent reply other threads:[~2020-07-01 21:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 4:13 [willy@infradead.org: Re: [PATCH 6/6] mm: Add memalloc_nowait] Matthew Wilcox
2020-07-01 21:35 ` Jonathan Corbet [this message]
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=20200701153532.63d49389@lwn.net \
--to=corbet@lwn.net \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=mpatocka@redhat.com \
--cc=neilb@suse.de \
--cc=rppt@kernel.org \
--cc=willy@infradead.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).