From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/3] f2fs crypto: use bounce pages from mempool first
Date: Wed, 27 May 2015 14:18:54 -0700 [thread overview]
Message-ID: <20150527211641.GA1397@jaegeuk-mac02.mot.com> (raw)
In-Reply-To: <20150525195551.GB16402@thunk.org>
On Mon, May 25, 2015 at 03:55:51PM -0400, Theodore Ts'o wrote:
> On Thu, May 21, 2015 at 05:40:24PM -0700, Jaegeuk Kim wrote:
> > If a lot of write streams are triggered, alloc_page and __free_page are
> > costly called, resulting in high memory pressure.
> >
> > In order to avoid that, let's reuse mempool pages for writeback pages.
>
> The reason why the mempool pages was used as a fallback was because
> once we are deep in the writeback code, handling memory allocation
> failures is close to impossible, since we've already made enough
> changes that unwinding them would be extremely difficult. So the
> basic idea was to use the mempool as an emergency reserve, since
> Failure Is Not An Option, and the alternative, which is to simply loop
> until the mm subsystem sees fit to give us a page, has sometimes led
> to deadlock.
So, in the current flow,
ciphertext_page = mempool_alloc(f2fs_bounce_page_pool, GFP_NOFS);
if (WARN_ON_ONCE(!ciphertext_page))
ciphertext_page = mempool_alloc(f2fs_bounce_page_pool,
GFP_NOFS | __GFP_WAIT);
^^^^^^^^^^^^
Was it intended __GFP_NOFAIL?
Anyway, f2fs handles ENOMEM in ->writepage by:
...
redirty_out:
redirty_page_for_writepage();
return AOP_WRITEPAGE_ACTIVATE;
}
>
> The primary source of write streams should be either (a) fsync
> operations, or (b) calls from the writeback thread. Are there any
> additional sources for f2fs? If they are calls from fsync operations,
> and we have more than a threshold number of write operations in play,
> we might want to think about blocking the fsync/fdatasync writeback,
> **before** the operation starts taking locks, so other write
> operations can proceed. And the writeback thread should keep the
> number of write operations to a reasonable number, especially given
> that we are treating page encryption as a blocking operation. Or is
> there something else going on which is making this to be more of a
> problem for f2fs?
The problem that I'd like to address here is to reduce the call counts of
allocating and freeing a number of pages in pairs.
When I conduct xfstests/224 under 1GB DRAM, I've seen triggering several oom
killers, and in that moment, a huge number of inactive anonymous pages are
registered in the page cache. Not sure why those pages are not reclaimed
seamlessly though.
Neverthelss, once I changed the flow to reuse the pages in the mempool for
encryption/decryption, I could have resolved that issue.
And, I thought that there is no reason to allocate new pages for every requests.
For general purpose, it may need an additional mempool too.
Thanks,
next prev parent reply other threads:[~2015-05-27 21:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 0:40 [PATCH 1/3] f2fs crypto: use per-inode tfm structure Jaegeuk Kim
2015-05-22 0:40 ` [PATCH 2/3] f2fs crypto: use bounce pages from mempool first Jaegeuk Kim
2015-05-25 10:00 ` [f2fs-dev] " Chao Yu
2015-05-27 19:09 ` Jaegeuk Kim
2015-05-29 2:45 ` Chao Yu
2015-05-25 19:55 ` Theodore Ts'o
2015-05-27 21:18 ` Jaegeuk Kim [this message]
2015-05-28 18:18 ` Theodore Ts'o
2015-05-29 19:10 ` nick
2015-05-28 4:21 ` [PATCH 2/3 v2] " Jaegeuk Kim
2015-05-22 0:40 ` [PATCH 3/3] f2fs crypto: preallocate BIO_MAX_PAGES for writeback Jaegeuk Kim
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=20150527211641.GA1397@jaegeuk-mac02.mot.com \
--to=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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).