Messages in this thread | | | Date | Wed, 26 Jul 2023 17:30:44 +0200 | Subject | Re: [PATCH] fuse: enable larger read buffers for readdir. | From | Bernd Schubert <> |
| |
On 7/26/23 17:26, Jaco Kroon wrote: > 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@uls.co.za> >>> --- >>> 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.
Yeah, the better choice is kvmalloc/kvfree which handles it internally.
> > I'm not familiar with the differences between the different mechanisms > available for allocation. > > -- snip -- > >> Thanks, > My pleasure, > Jaco
| |