Hi,
On 2023/07/26 15:53, Bernd Schubert wrote:
On 7/26/23 12:59, Jaco Kroon wrote:
Signed-off-by: Jaco Kroon <jaco@xxxxxxxxx>
---
fs/fuse/Kconfig | 16 ++++++++++++++++
fs/fuse/readdir.c | 42 ++++++++++++++++++++++++------------------
2 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/fs/fuse/Kconfig b/fs/fuse/Kconfig
index 038ed0b9aaa5..0783f9ee5cd3 100644
--- a/fs/fuse/Kconfig
+++ b/fs/fuse/Kconfig
@@ -18,6 +18,22 @@ config FUSE_FS
If you want to develop a userspace FS, or if you want to use
a filesystem based on FUSE, answer Y or M.
+config FUSE_READDIR_ORDER
+ int
+ range 0 5
+ default 5
+ help
+ readdir performance varies greatly depending on the size of
the read.
+ Larger buffers results in larger reads, thus fewer reads and
higher
+ performance in return.
+
+ You may want to reduce this value on seriously constrained
memory
+ systems where 128KiB (assuming 4KiB pages) cache pages is
not ideal.
+
+ This value reprents the order of the number of pages to
allocate (ie,
+ the shift value). A value of 0 is thus 1 page (4KiB) where
5 is 32
+ pages (128KiB).
+
I like the idea of a larger readdir size, but shouldn't that be a
server/daemon/library decision which size to use, instead of kernel
compile time? So should be part of FUSE_INIT negotiation?
Yes sure, but there still needs to be a default. And one page at a time
doesn't cut it.
-- snip --
- page = alloc_page(GFP_KERNEL);
+ page = alloc_pages(GFP_KERNEL, READDIR_PAGES_ORDER);
I guess that should become folio alloc(), one way or the other. Now I
think order 0 was chosen before to avoid risk of allocation failure. I
guess it might work to try a large size and to fall back to 0 when
that failed. Or fail back to the slower vmalloc.
If this varies then a bunch of other code will become somewhat more
complex, especially if one alloc succeeds, and then a follow-up succeeds.
I'm not familiar with the differences between the different mechanisms
available for allocation.
-- snip --
Thanks,
My pleasure,
Jaco
