Re: Re: Re: [PATCH v1] fuse: enable large folios

On Thu, Jun 25, 2026 at 11:37:23AM -0700, Joanne Koong wrote:
> On Thu, Jun 25, 2026 at 12:17 AM Horst Birthelmer <[email protected]> wrote:
> >
> > On Wed, Jun 24, 2026 at 10:52:11AM -0700, Joanne Koong wrote:
> > > On Tue, Jun 23, 2026 at 11:16 PM Horst Birthelmer <[email protected]> wrote:
> > > >
> > > > On Tue, Jun 23, 2026 at 06:21:32PM -0700, Joanne Koong wrote:
> > > > > Enable large folios, capping the max order at the largest request fuse
> > > > > can issue, so a folio always fits within a single request. The order
> > > > > range minimum is 0, so under memory pressure the allocator falls back to
> > > > > smaller folios.
> > > > >
> > > > > Benchmarks (libfuse passthrough_hp, buffered fio, single job, 4 GiB
> > > > > file, medians, NUMA-pinned, performance governor, strictlimiting on by
> > > > > default):
> > > > >
> > > > > tmpfs backing (page-cache bound):
> > > > >   workload          bs      large folios off   on        delta
> > > > >   seq read,  cold,  128k    3110 MiB/s    4514 MiB/s     +45%
> > > > >   seq read,  cold,  1M      3079 MiB/s    5181 MiB/s     +68%
> > > > >   seq read,  warm,  128k    2438 MiB/s    4486 MiB/s     +84%
> > > > >   seq read,  warm,  1M      2403 MiB/s    5123 MiB/s    +113%
> > > > >   writeback write, seq,128k 1211 MiB/s    1699 MiB/s     +40%
> > > > >   writeback write, seq, 1M  1462 MiB/s    2208 MiB/s     +51%
> > > > >   writeback write, rand,128k 1101 MiB/s   1757 MiB/s     +60% +
> > > > >   writeback write, rand, 1M 1284 MiB/s    2228 MiB/s     +74% +
> > > > >
> > > > > xfs on NVMe backing (device bound for cold I/O):
> > > > >   workload          bs      large folios off   on        delta
> > > > >   seq read,  cold,  128k    2030 MiB/s    2172 MiB/s      +7% *
> > > > >   seq read,  cold,  1M      1999 MiB/s    2181 MiB/s      +9% *
> > > > >   seq read,  warm,  128k    2451 MiB/s    4939 MiB/s    +101%
> > > > >   seq read,  warm,  1M      2340 MiB/s    5639 MiB/s    +141%
> > > > >   writeback write, seq,128k  637 MiB/s     747 MiB/s     +17% *
> > > > >   writeback write, seq, 1M   694 MiB/s     833 MiB/s     +20% *
> > > > >   writeback write, rand,128k 1004 MiB/s   1648 MiB/s     +64% +
> > > > >   writeback write, rand, 1M 1171 MiB/s    2055 MiB/s     +75% +
> > > > >
> > > >
> > > > Hi Joanne,
> > > >
> > > > just out of curiosity, did you disable bdi strict limiting for this?
> > >
> > > Hi Horst,
> > >
> > > Those results are with strictlimiting on. After commit 494d2f508883
> > > ('fuse: use default writeback accounting') [1], I didn't see any
> > > performance regressions anymore with large folios + strictlimiting on.
> > > More information on why that commit fixed the issue is in [2].
> > >
> > > When I ran the benchmarks last week with strictlimiting off, I saw roughly:
> > >     tmpfs:
> > >       seq,  128k    1174 -> 1648 MiB/s    +40%
> > >       seq,  1M      1261 -> 1845 MiB/s    +46%
> > >       rand, 128k    1148 -> 1638 MiB/s    +43%
> > >       rand, 1M      1273 -> 2065 MiB/s    +62%
> > >
> > >     xfs on NVMe:
> > >       seq,  128k     621 ->  740 MiB/s    +19%
> > >       seq,  1M       649 ->  776 MiB/s    +20%
> > >       rand, 128k    1020 -> 1515 MiB/s    +49%
> > >       rand, 1M      1125 -> 1895 MiB/s    +68%
> > >
> > > Strict limiting on actually had better performance here, which I think
> > > is because with the small dirty limit, the dirtying and the writeback
> > > happen in parallel instead of more dirty pages accumulating and then
> > > writeback getting kicked off. Because the backing device is so fast,
> > > it didn't cost throughput for the dirtying and the writeback to happen
> > > concurrently. The benchmarks were run with fsync, so everything had to
> > > be flushed before the fio run returned. If the backing device was slow
> > > and writes were bursty and fsync wasn't enforced, I think there'd
> > > probably be better performance with strictlimiting off than on, since
> > > the writer would be throttled to the speed of the backing device with
> > > strictlimtiing on.
> > >
> > > > In my tests esapcially the large writes run into throttling pretty
> > > > fast, so that it effectively writes pagewise, which was not the target
> > > > of the test.
> > >
> > > Are you seeing this on your system with strictlimiting on or off? Is
> > > that with commit 494d2f508883 in your tree? What test and server were
> > > you running? Do you know what the speed of the backing device is?
> >
> > Without your patch I see that when I enable strict limiting most
> 
> Which patch are you referring to? The patch that turns on large folios
> or the patch that fixes the writeback accounting? Are you seeing this
> with large folios off or on?

Large folios enabled and fuse own accounting, so your patch that removes
the own accounting not applied.

> 
> Thanks,
> Joanne
> 
> > FUSE_WRITE requests in the fuse server are 4k. With it disabled the
> > writes are triggered with larger sizes.
> > Since bdi min_ratio is 0 by default I just assumed that as soon as the
> > cache gets over the limit a write with that page is triggered.