From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>,
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, 4 Sep 2014 09:05:23 +0100 [thread overview]
Message-ID: <540555BE-7985-4468-BC03-45CDA7E2EB83@cam.ac.uk> (raw)
In-Reply-To: <20140903193058.2bc891a7.akpm@linux-foundation.org>
On 4 Sep 2014, at 03:30, Andrew Morton <akpm@linux-foundation.org> wrote:
> __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.
I think what it really boils down to is that file systems cannot allow recursion into _that_ file system so if VFS/VM shrinking could skip over all inodes/dentries/pages that are associated with the superblock of the volume for which the allocation is being done then that would be just fine.
An alternative would be that the file systems would need to be passed in a flag that will tell them that it is not safe to take locks and then file systems that need to take a lock could return with -EDEADLOCK and the VM can then skip over those entries and reclaim others. Though I think it would be more efficient for the VFS/VM to simply not call into the file system that is doing the allocation as above...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
University of Cambridge Information Services, Roger Needham Building
7 JJ Thomson Avenue, Cambridge, CB3 0RB, UK
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-09-04 8:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 5:54 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
2014-09-04 8:05 ` Anton Altaparmakov [this message]
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=540555BE-7985-4468-BC03-45CDA7E2EB83@cam.ac.uk \
--to=aia21@cam.ac.uk \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=junxiao.bi@oracle.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