Re: [PATCH] fuse: disable default bdi strictlimiting

["Darrick J. Wong" <djwong@kernel.org>]

[cc willy in case he has opinions about dynamically changing the
pagecache order range]

On Thu, Oct 09, 2025 at 11:36:30AM -0700, Joanne Koong wrote:
> On Thu, Oct 9, 2025 at 7:17 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > On Wed, 8 Oct 2025 at 22:42, Joanne Koong <joannelkoong@gmail.com> wrote:
> >
> > > Since fuse now uses proper writeback accounting without temporary pages,
> > > strictlimiting is no longer needed. Additionally, for fuse large folio
> > > buffered writes, strictlimiting is overly conservative and causes
> > > suboptimal performance due to excessive IO throttling.
> >
> > I don't quite get this part.  Is this a fuse specific limitation of
> > stritlimit vs. large folios?
> >
> > Or is it the case that other filesystems are also affected, but
> > strictlimit is never used outside of fuse?
> 
> It's the combination of fuse doing strictlimiting and setting the bdi
> max ratio to 1%.
> 
> I don't think this is fuse-specific. I ran the same fio job [1]
> locally on xfs and with setting the bdi max ratio to 1%, saw
> performance drops between strictlimiting off vs. on
> 
> [1] fio --name=write --ioengine=sync --rw=write --bs=256K --size=1G
> --numjobs=2 --ramp_time=30 --group_reporting=1

Er... what kind of numbers? :)

> >
> > > Administrators can still enable strictlimiting for specific fuse servers
> > > via /sys/class/bdi/*/strict_limit. If needed in the future,
> >
> > What's the issue with doing the opposite: leaving strictlimit the
> > default and disabling strictlimit for specific servers?
> 
> If we do that, then we can't enable large folios for servers that use
> the writeback cache. I don't think we can just turn on large folios if

What's the limitation on strictlimit && large_folios?  Is it just the
throttling problem because dirtying a single byte in a 2M folio charges
the process with all 2M?  Or something else?

> an admin later on disables strictlimiting for the server, because I
> don't think mapping_set_folio_order_range() can be called after the
> inode has been initialized (not 100% sure about this), which means
> we'd also need to add some mount option for servers to disable
> strictlimiting.

I think it's ok to increase the folio order range at runtime because
you're merely expanding the range of valid folio sizes in the mapping.

Decreasing the range probably won't work unless you take the inode and
mapping locks exclusively and purge the pagecache.

--D

> Thanks,
> Joanne
> >
> > Thanks,
> > Miklos
>