diff mbox series

[1/1] xfs: map xfile pages directly into xfs_buf

Message ID 170404997970.1797094.13056398021609108212.stgit@frogsfrogsfrogs (mailing list archive)
State New
Headers show
Series [1/1] xfs: map xfile pages directly into xfs_buf | expand

Commit Message

Darrick J. Wong Dec. 31, 2023, 10:35 p.m. UTC
From: Darrick J. Wong <djwong@kernel.org>

Map the xfile pages directly into xfs_buf to reduce memory overhead.
It's silly to use memory to stage changes to shmem pages for ephemeral
btrees that don't care about transactionality.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 libxfs/xfs_btree_mem.h  |    6 ++++++
 libxfs/xfs_rmap_btree.c |    1 +
 2 files changed, 7 insertions(+)

Comments

Christoph Hellwig Jan. 3, 2024, 8:24 a.m. UTC | #1
On Sun, Dec 31, 2023 at 02:35:23PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Map the xfile pages directly into xfs_buf to reduce memory overhead.
> It's silly to use memory to stage changes to shmem pages for ephemeral
> btrees that don't care about transactionality.

Looking at the users if seems like this is in fact the online use
case - PAGE_SIZE sized btree blocks, which by nature of coming from
shmem must be aligned.  So I'd suggest we remove the non-mapped
file path and just always use this one with sufficient sanity checks
to trip over early if that assumption doesn't hold true.

The users also alway just has a single map per buffer, and a single
page per buffer so it really shouldn't support anything else.

Writing it directly to shmemfs will probably simply things as well
as it just needs to do a shmem_read_mapping_page_gfp to read the one
page per buffer, and then a set_page_dirty on the locked page when
releasing it.

Talking about relasing it:  this now gets us back to the old pagebuf
problem of competing LRUs, one for the xfs_buf, and then anothr for
the shmemfs page in the page cache.  I suspect not putting the shmemfs
backed buffers onto the LRU at all might be a good thing, but that
requires careful benchmarking.
Christoph Hellwig Jan. 3, 2024, 8:44 a.m. UTC | #2
This comment should have been for the kernel version and not the
userspace artefact patch.
diff mbox series

Patch

diff --git a/libxfs/xfs_btree_mem.h b/libxfs/xfs_btree_mem.h
index 1f961f3f554..cfb30cb1aab 100644
--- a/libxfs/xfs_btree_mem.h
+++ b/libxfs/xfs_btree_mem.h
@@ -17,8 +17,14 @@  struct xfbtree_config {
 
 	/* Owner of this btree. */
 	unsigned long long		owner;
+
+	/* XFBTREE_* flags */
+	unsigned int			flags;
 };
 
+/* buffers should be directly mapped from memory */
+#define XFBTREE_DIRECT_MAP		(1U << 0)
+
 #ifdef CONFIG_XFS_BTREE_IN_XFILE
 unsigned int xfs_btree_mem_head_nlevels(struct xfs_buf *head_bp);
 
diff --git a/libxfs/xfs_rmap_btree.c b/libxfs/xfs_rmap_btree.c
index a378bd5daf8..7342623ed5e 100644
--- a/libxfs/xfs_rmap_btree.c
+++ b/libxfs/xfs_rmap_btree.c
@@ -670,6 +670,7 @@  xfs_rmapbt_mem_create(
 		.btree_ops	= &xfs_rmapbt_mem_ops,
 		.target		= target,
 		.owner		= agno,
+		.flags		= XFBTREE_DIRECT_MAP,
 	};
 
 	return xfbtree_create(mp, &cfg, xfbtreep);