From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Michal Hocko <mhocko@kernel.org>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
"Theodore Ts'o" <tytso@mit.edu>, Chris Mason <clm@fb.com>,
Jan Kara <jack@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 1/2] mm: add PF_MEMALLOC_NOFS
Date: Wed, 27 Apr 2016 19:53:21 +0900 [thread overview]
Message-ID: <32e220de-6028-a32c-e6a5-6935b97d277d@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <1461671772-1269-2-git-send-email-mhocko@kernel.org>
On 2016/04/26 20:56, Michal Hocko wrote:
> Not only this is easier to understand and maintain because there are
> much less problematic contexts than specific allocation requests, this
> also helps code paths where FS layer interacts with other layers (e.g.
> crypto, security modules, MM etc...) and there is no easy way to convey
> the allocation context between the layers.
>
You arrived at what I wished at
http://lkml.kernel.org/r/201503172305.DIH52162.FOFMFOVJHLOtQS@I-love.SAKURA.ne.jp
(i.e. not CONFIG_DEBUG_* but always enabled).
> Introduce PF_MEMALLOC_NOFS task specific flag and memalloc_nofs_{save,restore}
> API to control the scope. This is basically copying
> memalloc_noio_{save,restore} API we have for other restricted allocation
> context GFP_NOIO.
>
> Xfs has already had a similar functionality as PF_FSTRANS so let's just
> give it a more generic name and make it usable for others as well and
> move the GFP_NOFS context tracking to the page allocator. Xfs has its
> own accessor functions but let's keep them for now to reduce this patch
> as minimum.
>
> This patch shouldn't introduce any functional changes. Xfs code paths
> preserve their semantic. kmem_flags_convert() doesn't need to evaluate
> the flag anymore because it is the page allocator to care about the
> flag. memalloc_noio_flags is renamed to current_gfp_context because it
> now cares about both PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO contexts.
>
> Let's hope that filesystems will drop direct GFP_NOFS (resp. ~__GFP_FS)
> usage as much and possible and only use a properly documented
> memalloc_nofs_{save,restore} checkpoints where they are appropriate.
Is the story simple enough to monotonically replace GFP_NOFS/GFP_NOIO
with GFP_KERNEL after memalloc_no{fs,io}_{save,restore} are inserted?
We sometimes delegate some operations to somebody else. Don't we need to
convey PF_MEMALLOC_NOFS/PF_MEMALLOC_NOIO flags to APIs which interact with
other threads?
next prev parent reply other threads:[~2016-04-27 10:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 11:56 [PATCH 0/2] scop GFP_NOFS api Michal Hocko
2016-04-26 11:56 ` [PATCH 1/2] mm: add PF_MEMALLOC_NOFS Michal Hocko
2016-04-26 23:07 ` Dave Chinner
2016-04-27 7:51 ` Michal Hocko
2016-04-27 10:53 ` Tetsuo Handa [this message]
2016-04-27 11:15 ` Michal Hocko
2016-04-27 14:44 ` Tetsuo Handa
2016-04-27 20:05 ` Michal Hocko
2016-04-27 11:54 ` [PATCH 1.1/2] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS Michal Hocko
2016-04-27 11:54 ` [PATCH 1.2/2] mm: introduce memalloc_nofs_{save,restore} API Michal Hocko
2016-04-27 13:07 ` Michal Hocko
2016-04-27 20:09 ` Michal Hocko
2016-04-27 20:30 ` Michal Hocko
2016-04-27 21:14 ` Michal Hocko
2016-04-27 17:41 ` [PATCH 1.1/2] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS Andreas Dilger
2016-04-27 19:43 ` Michal Hocko
2016-04-26 11:56 ` [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context Michal Hocko
2016-04-26 22:58 ` Dave Chinner
2016-04-27 8:03 ` Michal Hocko
2016-04-27 22:55 ` Dave Chinner
2016-04-28 8:17 ` Michal Hocko
2016-04-28 21:51 ` Dave Chinner
2016-04-29 12:12 ` Michal Hocko
2016-04-29 23:40 ` Dave Chinner
2016-05-03 15:38 ` Michal Hocko
2016-05-04 0:07 ` Dave Chinner
2016-04-29 5:35 ` [PATCH 0/2] scop GFP_NOFS api NeilBrown
2016-04-29 10:20 ` [Cluster-devel] " Steven Whitehouse
2016-04-30 21:17 ` NeilBrown
2016-04-29 12:04 ` Michal Hocko
2016-04-30 0:24 ` Dave Chinner
2016-04-30 21:55 ` NeilBrown
2016-05-03 15:13 ` Michal Hocko
2016-05-03 23:26 ` NeilBrown
2016-04-30 0:11 ` Dave Chinner
2016-04-30 22:19 ` NeilBrown
2016-05-04 1:00 ` Dave Chinner
2016-05-06 3:20 ` NeilBrown
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=32e220de-6028-a32c-e6a5-6935b97d277d@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=clm@fb.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.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 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).