From: David Laight <david.laight.linux@gmail.com>
To: Jaco Kroon <jaco@uls.co.za>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
bernd.schubert@fastmail.fm, miklos@szeredi.hu,
rdunlap@infradead.org, trapexit@spawn.link
Subject: Re: fuse: increase readdir() buffer size
Date: Fri, 28 Mar 2025 19:40:07 +0000 [thread overview]
Message-ID: <20250328194007.4768eaf9@pumpkin> (raw)
In-Reply-To: <05b36be3-f43f-4a49-9724-1a0d8d3a8ce4@uls.co.za>
On Fri, 28 Mar 2025 12:15:47 +0200
Jaco Kroon <jaco@uls.co.za> wrote:
> Hi All,
>
> I've not seen feedback on this, please may I get some direction on this?
The only thing I can think of is that the longer loop might affect
scheduling latencies.
David
>
> Kind regards,
> Jaco
>
> On 2025/03/15 00:16, Jaco Kroon wrote:
> > This is a follow up to the attempt made a while ago.
> >
> > Whist the patch worked, newer kernels have moved from pages to folios,
> > which gave me the motivation to implement the mechanism based on the
> > userspace buffer size patch that Miklos supplied.
> >
> > That patch works as is, but I note there are changes to components
> > (overlayfs and exportfs) that I've got very little experience with, and
> > have not tested specifically here. They do look logical. I've marked
> > Miklos as the Author: here, and added my own Signed-off-by - I hope this
> > is correct.
> >
> > The second patch in the series implements the changes to fuse's readdir
> > in order to utilize the first to enable reading more than one page of
> > dent structures at a time from userspace, I've included a strace from
> > before and after this patch in the commit to illustrate the difference.
> >
> > To get the relevant performance on glusterfs improved (which was
> > mentioned elsewhere in the thread) changes to glusterfs to increase the
> > number of cached dentries is also required (these are pushed to github
> > but not yet merged, because similar to this patch, got stalled before
> > getting to the "ready for merge" phase even though it's operational).
> >
> > Please advise if these two patches looks good (I've only done relatively
> > basic testing now, and it's not running on production systems yet)
> >
> > Kind regards,
> > Jaco
> >
>
next prev parent reply other threads:[~2025-03-28 19:40 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 10:59 [PATCH] fuse: enable larger read buffers for readdir Jaco Kroon
2023-07-26 11:43 ` Jaco Kroon
2023-07-26 13:53 ` Bernd Schubert
2023-07-26 15:26 ` Jaco Kroon
2023-07-26 15:30 ` Bernd Schubert
2023-07-26 15:45 ` Bernd Schubert
2023-07-26 17:23 ` Antonio SJ Musumeci
2023-07-26 18:25 ` Jaco Kroon
2023-07-27 15:21 ` Miklos Szeredi
2023-07-27 19:21 ` Miklos Szeredi
2023-07-27 19:43 ` Bernd Schubert
2023-07-28 8:42 ` Miklos Szeredi
2023-07-26 15:19 ` Randy Dunlap
2023-07-27 8:12 ` [PATCH] fuse: enable larger read buffers for readdir [v2] Jaco Kroon
2023-07-27 15:35 ` Miklos Szeredi
2023-07-27 16:58 ` Jaco Kroon
2023-07-27 19:17 ` Miklos Szeredi
2023-07-27 19:16 ` Bernd Schubert
2023-07-27 20:35 ` Bernd Schubert
2023-07-28 5:05 ` Jaco Kroon
2025-03-14 22:16 ` fuse: increase readdir() buffer size Jaco Kroon
2025-03-14 22:16 ` [PATCH 1/2] fs: Supply dir_context.count as readdir buffer size hint Jaco Kroon
2025-03-29 9:20 ` Christophe JAILLET
2025-03-30 14:27 ` Jaco Kroon
2025-03-14 22:16 ` [PATCH 2/2] fuse: Adjust readdir() buffer to requesting buffer size Jaco Kroon
2025-03-31 16:41 ` Joanne Koong
2025-03-31 20:43 ` Jaco Kroon
2025-03-31 21:48 ` Joanne Koong
2025-03-31 23:01 ` Joanne Koong
2025-03-28 10:15 ` fuse: increase readdir() " Jaco Kroon
2025-03-28 10:16 ` Bernd Schubert
2025-03-28 19:40 ` David Laight [this message]
2025-03-29 8:59 ` Jaco Kroon
2025-04-01 14:18 ` fuse: increase readdir() buffer size [v4] Jaco Kroon
2025-04-01 14:18 ` [PATCH 1/2] fs: Supply dir_context.count as readdir buffer size hint Jaco Kroon
2025-04-01 14:18 ` [PATCH 2/2] fuse: Adjust readdir() buffer to requesting buffer size Jaco Kroon
2025-04-01 14:40 ` Miklos Szeredi
2025-04-01 15:03 ` Jaco Kroon
2025-04-01 15:33 ` Miklos Szeredi
2025-04-02 7:54 ` Jaco Kroon
2025-04-02 8:18 ` Miklos Szeredi
2025-04-02 8:52 ` Jaco Kroon
2025-04-02 9:10 ` Bernd Schubert
2025-04-02 11:13 ` Jaco Kroon
2025-04-02 11:35 ` Miklos Szeredi
2025-04-02 11:59 ` Bernd Schubert
2025-04-08 14:19 ` Bernd Schubert
2025-04-09 7:12 ` Jaco Kroon
2025-04-09 8:31 ` Bernd Schubert
2025-04-09 15:03 ` Jaco Kroon
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=20250328194007.4768eaf9@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=bernd.schubert@fastmail.fm \
--cc=jaco@uls.co.za \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=rdunlap@infradead.org \
--cc=trapexit@spawn.link \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.