Re: [PATCH] fuse: add folio_max_order and folio_min_order controls in fusectl

[Swetha Vadlakonda]

On Tue, Jul 7, 2026 at 2:40 AM Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
>
> On Fri, Jul 3, 2026 at 2:31 AM Vadlakonda Swetha <swethav0411@xxxxxxxxx> wrote:
> >
> > Expose `folio_max_order` and `folio_min_order` entries under the FUSE
> > control filesystem (`/sys/fs/fuse/connections/<connection_id>/`).
> >
> > Motivation:
> > For fuse based systems like GCSFuse (Google Cloud Storage Fuse), large
> > folios gives a significant boost to the read performance.
> > - Without large folios, single file read perf is capped at 3GiB/s
> > - With large folios, we are able to achieve 12GiB/s, 1MB blocksize
> > - Writes:2GiB/s with large folios vs 1.6GiB/s without folios for 1MB bs
> >
> > We understand that subfolio dirty page tracking is not available for
> > writeback cache with large folios. However this is not a blocker for
>
> The buffered write and writeback paths in fuse go through iomap which
> tracks subfolio dirty state.

Thanks for the review and update. I was under the impression that not
all changes
related to subfolio dirty page tracking are done.
>
> > GCSFuse and similar cloud/network-based filesystems for the following
> > reasons:
> >
> > 1. We generally recommend applications to use larger io sizes (>1MB)
> >    for writes because of the latency involved with the network calls.
> > 2. Random writes & small overwrites are also not recommended for cloud
> >    based filesystems.
> > 3. Beneficial when write back cache is explicitly disabled. Incase of
> >    GCSFuse, write back cache is disabled for different other reasons.
> >
> > Providing these controls allow individual filesystems to explicitly opt
> > into large folios once they evaluate their specific workload patterns.
>
> Could you explain the use case of this granularity? The page cache
> already adjusts folio size adaptively (eg small/random i/o still has
> small orders, high-order allocations fall back gracefully to
> lower-order allocations under memory pressure, etc) so it's a bit
> unclear to me why a tunable would be needed. It also won't enforce the
> order for any inodes that are already in the cache.

Our primary motivation was to give fine-grained control and users can set
it as per their workload requirements. But agreed on the fallback strategy and
have a single on/off switch.
>
> There's a patch to enable large folios by default [1] and the
> benchmark numbers showed improvements all around, so I don't think
> this would be something individual filesystems would have to
> explicitly opt into. Does the change in [1] suffice for your use case?

Yes, the change in [1] completely suffices for GCSFuse.