News › performance
By The Linux Camp News, September 29, 2026
The patch enables larger memory-management units within FUSE request limits. Author benchmarks show substantial buffered-read gains, but device-bound workloads benefit less and Linux 7.4 inclusion remains unconfirmed.
Miklos Szeredi committed Joanne Koong’s FUSE large-folio enablement patch on September 25, 2026, following its September 16 author date. As of the September 29 source retrieval, Phoronix reported it in FUSE’s for-next development branch, with Linux 7.4 inclusion expected. That establishes a development milestone for filesystems implemented in userspace, not confirmation that the change has reached mainline or a released kernel. 2 1
A large folio groups contiguous physical memory pages into one management unit, reducing per-folio overhead. The patch sets the allowed folio-size range for a file’s mapping. Its upper bound comes from the smallest of the connection’s write-size, read-size and page-count limits, so a folio fits within one FUSE request rather than spanning requests. The change therefore permits larger units without ignoring the connection’s existing transfer constraints. 1 2
Larger allocations are permitted, not mandatory. The minimum allocation order remains zero, allowing fallback to smaller folios under memory pressure. This is more precise than treating memory pressure as an on/off switch for the feature. The code also returns before enabling large folios for inodes marked DAX, explicitly excluding that path. 3 2
The performance evidence is Koong’s reported benchmark comparison, not independent replication. It uses libfuse passthrough_hp with buffered fio, one job and a 4 GiB file. Results are medians, with NUMA pinning, the performance governor and strictlimiting enabled by default. Those conditions matter: this tests a specific userspace filesystem implementation and buffered workload, rather than establishing gains across all FUSE deployments. 3 2
The strongest read results came with warm caches. At a 1M block size, tmpfs-backed sequential reads rose from 2,403 to 5,123 MiB/s, a reported 113% increase; cold reads rose from 3,079 to 5,181 MiB/s, or 68%. With XFS on NVMe, warm sequential reads at the same block size increased from 2,340 to 5,639 MiB/s, or 141%. These are measured comparisons in the author’s setup, not throughput guarantees. 2 3
The backing-device bottleneck changes the outcome. Cold sequential reads on XFS/NVMe improved only 7–9%, although Koong reports roughly halved system CPU utilization in the device-bandwidth-bound cases. The reported random-write gains also need qualification: those tests overwrote a hot region under writeback, making them page-cache-bound. Their improvement reflects lower per-folio CPU overhead, not a faster backing device. 2 3
For an evaluation, the practical inference is to compare CPU utilization as well as throughput, separate warm-cache from cold-cache runs, and match the production write mode. Otherwise, a device bottleneck or cache-resident overwrite test could obscure what changed. Do not assume every workload benefits: the author reports neutral results for 4k and 128k random reads and for writethrough writes, with no observed read-modify-write or read-amplification penalty in those tests. The supplied single-job buffered results do not establish behavior under concurrency, direct I/O or memory pressure. 2 3