From: Theodore Ts'o <tytso@mit.edu>
To: linux-mm@kvack.org, linux-ext4@vger.kernel.org
Subject: Best way to pin a page in ext4?
Date: Mon, 15 Sep 2014 14:51:01 -0400 (EDT) [thread overview]
Message-ID: <20140915185102.0944158037A@closure.thunk.org> (raw)
Hi,
In ext4, we currently use the page cache to store the allocation
bitmaps. The pages are associated with an internal, in-memory inode
which is located in EXT4_SB(sb)->s_buddy_cache. Since the pages can be
reconstructed at will, either by reading them from disk (in the case of
the actual allocation bitmap), or by calculating the buddy bitmap from
the allocation bitmap, normally we allow the VM to eject the pags as
necessary.
For a specialty use case, I've been requested to have an optional mode
where the on-disk bitmaps are pinned into memory; this is a situation
where the file system size is known in advance, and the user is willing
to trade off the locked-down memory for the latency gains required by
this use case.
It seems that the simplest way to do that is to use mlock_vma_page()
when the file system is first mounted, and then use munlock_vma_page()
when the file system is unmounted. However, these functions are in
mm/internal.h, so I figured I'd better ask permission before using
them. Does this sound like a sane way to do things?
The other approach would be to keep an elevated refcount on the pages in
question, but it seemed it would be more efficient use the mlock
facility since that keeps the pages on an unevictable list.
Does using the mlock/munlock_vma_page() functions make sense? Any
pitfalls I should worry about? Note that these pages are never mapped
into userspace, so there is no associated vma; fortunately the functions
don't take a vma argument, their name notwithstanding.....
Thanks,
- Ted
--
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 reply other threads:[~2014-09-15 18:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 18:51 Theodore Ts'o [this message]
2014-09-15 20:57 ` Andreas Dilger
2014-09-16 18:07 ` Theodore Ts'o
2014-09-16 18:34 ` Christoph Lameter
2014-09-16 18:56 ` Theodore Ts'o
2014-09-17 0:07 ` Hugh Dickins
2014-09-17 1:25 ` Theodore Ts'o
2014-09-17 3:31 ` Christoph Lameter
2014-09-17 13:57 ` Peter Zijlstra
2014-09-17 20:37 ` Hugh Dickins
2014-09-17 13:56 ` Peter Zijlstra
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=20140915185102.0944158037A@closure.thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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