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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>