On Tue, Aug 12, 2025 at 12:38 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> On Tue, Aug 12, 2025 at 01:13:57PM +0200, Miklos Szeredi wrote:
> > On Mon, 11 Aug 2025 at 23:13, Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
> > >
> > > On Mon, Aug 11, 2025 at 1:43 PM Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
> > > >
> > > > Large folios are only enabled if the writeback cache isn't on.
> > > > (Strictlimiting needs to be turned off if the writeback cache is used in
> > > > conjunction with large folios, else this tanks performance.)
> >
> > Is there an explanation somewhere about the writeback cache vs.
> > strictlimit issue?
>
> and, for n00bs such as myself: what is "strictlimit"? :)
>
My understanding of strictlimit is that it's a way of preventing
non-trusted filesystems from dirtying too many pages too quickly and
thus taking up too much bandwidth. It imposes stricter / more
conservative limits on how many pages a filesystem can dirty before it
gets forcibly throttled (the bulk of the logic happens in
balance_dirty_pages()). This is needed for fuse because fuse servers
may be unprivileged and malicious or buggy. The feature was introduced
in commit 5a53748568f7 ("mm/page-writeback.c: add strictlimit
feature). The reason we now run into this is because with large
folios, the dirtying happens so much faster now (eg a 1MB folio is
dirtied and copied at once instead of page by page), and as a result
the fuse server gets throttled more while doing large writes, which
ends up making the write overall slower.
Thanks,
Joanne
> --D
>
> > Thanks,
> > Miklos
> >
