From: Joanne Koong <joannelkoong@gmail.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org, jefflexu@linux.alibaba.com,
bernd.schubert@fastmail.fm, willy@infradead.org,
kernel-team@meta.com
Subject: Re: [PATCH] fuse: enable large folios (if writeback cache is unused)
Date: Wed, 13 Aug 2025 10:40:40 -0700 [thread overview]
Message-ID: <CAJnrk1b74j2YETzVJ83cdsyojye5bwmUYAymCFrAcDjsOLcDYQ@mail.gmail.com> (raw)
In-Reply-To: <20250813012017.GM7942@frogsfrogsfrogs>
On Tue, Aug 12, 2025 at 6:20 PM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Tue, Aug 12, 2025 at 04:02:12PM -0700, Joanne Koong wrote:
> > On Tue, Aug 12, 2025 at 12:38 PM Darrick J. Wong <djwong@kernel.org> wrote:
> > >
> > 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
>
> Oh, BDI_CAP_STRICTLIMIT.
>
> /me digs
>
> "Then wb_thresh is 1% of 20% of 16GB. This amounts to ~8K pages."
>
> Oh wow.
>
> > 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.
>
> <nod> and hence your patchset gives the number of dirty blocks (pages?)
> within the large folio to the writeback throttling code so that you
> don't get charged for 2M of dirty data if you've really only touched a
> single byte of a 2M folio, right?
>
Yeah, exactly!
> Will go have a look at that tomorrow.
Thanks!
>
> --D
>
next prev parent reply other threads:[~2025-08-13 17:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 20:40 [PATCH] fuse: enable large folios (if writeback cache is unused) Joanne Koong
2025-08-11 21:13 ` Joanne Koong
2025-08-12 3:25 ` Chunsheng Luo
2025-08-12 22:14 ` Joanne Koong
2025-08-12 11:13 ` Miklos Szeredi
2025-08-12 19:38 ` Darrick J. Wong
2025-08-12 23:02 ` Joanne Koong
2025-08-13 1:20 ` Darrick J. Wong
2025-08-13 17:40 ` Joanne Koong [this message]
2025-08-13 8:20 ` Miklos Szeredi
2025-08-13 18:05 ` Joanne Koong
2025-08-12 22:44 ` Joanne Koong
2025-08-15 11:01 ` Jingbo Xu
2025-08-15 16:16 ` Joanne Koong
2025-08-16 1:45 ` Jingbo Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJnrk1b74j2YETzVJ83cdsyojye5bwmUYAymCFrAcDjsOLcDYQ@mail.gmail.com \
--to=joannelkoong@gmail.com \
--cc=bernd.schubert@fastmail.fm \
--cc=djwong@kernel.org \
--cc=jefflexu@linux.alibaba.com \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).