From: Junxiao Bi <junxiao.bi@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: david@fromorbit.com, xuejiufei@huawei.com,
ming.lei@canonical.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set
Date: Thu, 04 Sep 2014 12:57:08 +0800 [thread overview]
Message-ID: <5407F124.5070203@oracle.com> (raw)
In-Reply-To: <20140903193058.2bc891a7.akpm@linux-foundation.org>
On 09/04/2014 10:30 AM, Andrew Morton wrote:
> On Thu, 04 Sep 2014 10:08:09 +0800 Junxiao Bi <junxiao.bi@oracle.com> wrote:
>
>> On 09/04/2014 07:10 AM, Andrew Morton wrote:
>>> On Wed, 3 Sep 2014 13:54:54 +0800 Junxiao Bi <junxiao.bi@oracle.com> wrote:
>>>
>>>> commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O during memory allocation")
>>>> introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory allocation, __GFP_IO is cleared
>>>> when this flag is set, but __GFP_FS implies __GFP_IO, it should also be cleared. Or it may still
>>>> run into I/O, like in superblock shrinker.
>>>
>>> Is there an actual bug which inspired this fix? If so, please describe
>>> it.
>>>
>> Yes, an ocfs2 deadlock bug is related to this, there is a workqueue in
>> ocfs2 who is for building tcp connections and processing ocfs2 message.
>> Like when an new node is up in ocfs2 cluster, the workqueue will try to
>> build the connections to it, since there are some common code in
>> networking like sock_alloc() using GFP_KERNEL to allocate memory, direct
>> reclaim will be triggered and call into superblock shrinker if available
>> memory is not enough even set PF_MEMALLOC_NOIO for the workqueue. To
>> shrink the inode cache, ocfs2 needs release cluster lock and this
>> depends on workqueue to do it, so cause the deadlock. Not sure whether
>> there are similar issue for other cluster fs, like nfs, it is possible
>> rpciod hung like the ocfs2 workqueue?
>
> All this info should be in the changelog.
>
>>
>>> I don't think it's accurate to say that __GFP_FS implies __GFP_IO.
>>> Where did that info come from?
>> __GFP_FS allowed callback into fs during memory allocation, and fs may
>> do io whatever __GFP_IO is set?
>
> __GFP_FS and __GFP_IO are (or were) for communicating to vmscan: don't
> enter the fs for writepage, don't write back swapcache.
>
> I guess those concepts have grown over time without a ton of thought
> going into it. Yes, I suppose that if a filesystem's writepage is
> called (for example) it expects that it will be able to perform
> writeback and it won't check (or even be passed) the __GFP_IO setting.
>
> So I guess we could say that !__GFP_FS && GFP_IO is not implemented and
> shouldn't occur.
>
> That being said, it still seems quite bad to disable VFS cache
> shrinking for PF_MEMALLOC_NOIO allocation attempts.
Even without this ocfs2 deadlock bug, the implement of PF_MEMALLOC_NOIO
is wrong. See the deadlock case described in its log below. Let see the
case "block device runtime resume", since __GFP_FS is not cleared, it
could run into fs writepage and cause deadlock.
next prev parent reply other threads:[~2014-09-04 4:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 5:54 [PATCH] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set Junxiao Bi
2014-09-03 12:20 ` Trond Myklebust
2014-09-04 2:18 ` Junxiao Bi
2014-09-03 23:10 ` Andrew Morton
2014-09-04 2:08 ` Junxiao Bi
2014-09-04 2:30 ` Andrew Morton
2014-09-04 4:57 ` Junxiao Bi [this message]
2014-09-04 8:05 ` Anton Altaparmakov
2014-09-04 9:21 ` Dave Chinner
2014-09-04 9:05 ` Dave Chinner
2014-09-04 9:23 ` Dave Chinner
2014-09-05 2:32 ` Junxiao Bi
2014-09-05 5:13 ` Junxiao Bi
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=5407F124.5070203@oracle.com \
--to=junxiao.bi@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ming.lei@canonical.com \
--cc=xuejiufei@huawei.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).