From: Dave Chinner <david@fromorbit.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Theodore Ts'o" <tytso@mit.edu>, Chris Mason <clm@fb.com>,
Jan Kara <jack@suse.cz>,
ceph-devel@vger.kernel.org, cluster-devel@redhat.com,
linux-nfs@vger.kernel.org, logfs@logfs.org, xfs@oss.sgi.com,
linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-mtd@lists.infradead.org, reiserfs-devel@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net,
linux-f2fs-devel@lists.sourceforge.net,
linux-afs@lists.infradead.org,
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 09:07:02 +1000 [thread overview]
Message-ID: <20160426230702.GG26977@dastard> (raw)
In-Reply-To: <1461671772-1269-2-git-send-email-mhocko@kernel.org>
On Tue, Apr 26, 2016 at 01:56:11PM +0200, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> GFP_NOFS context is used for the following 4 reasons currently
> - to prevent from deadlocks when the lock held by the allocation
> context would be needed during the memory reclaim
> - to prevent from stack overflows during the reclaim because
> the allocation is performed from a deep context already
> - to prevent lockups when the allocation context depends on
> other reclaimers to make a forward progress indirectly
> - just in case because this would be safe from the fs POV
- silencing lockdep false positives
> 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.
Can you split this into two patches? The first simply does this:
#define PF_MEMALLOC_NOFS PF_FSTRANS
and changes only the XFS code to use PF_MEMALLOC_NOFS.
The second patch can then do the rest of the mm API changes that we
don't actually care about in XFS at all. That way I can carry all
the XFS changes in the XFS tree and not have to worry about when
this stuff gets merged or conflicts with the rest of the work that
is being done to the mm/ code and whatever tree that eventually
lands in...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-04-26 23:07 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 [this message]
2016-04-27 7:51 ` Michal Hocko
2016-04-27 10:53 ` Tetsuo Handa
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=20160426230702.GG26977@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=ceph-devel@vger.kernel.org \
--cc=clm@fb.com \
--cc=cluster-devel@redhat.com \
--cc=jack@suse.cz \
--cc=linux-afs@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-ntfs-dev@lists.sourceforge.net \
--cc=logfs@logfs.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=reiserfs-devel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=xfs@oss.sgi.com \
/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).