All of lore.kernel.org
 help / color / mirror / Atom feed
From: Horst Birthelmer <horst@birthelmer.de>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Joanne Koong <joannelkoong@gmail.com>,
	linux-fsdevel@vger.kernel.org,  kernel-team@meta.com,
	fuse-devel <fuse-devel@lists.sourceforge.net>
Subject: Re: Re: [PATCH] fuse: disable default bdi strictlimiting
Date: Fri, 8 May 2026 13:54:39 +0200	[thread overview]
Message-ID: <af3NyD5QDK6pmbR_@fedora.fritz.box> (raw)
In-Reply-To: <CAJfpegsy2XRR6g1J4Mg0MXPckx3NVprW56XvYhEko0=7PcHiQQ@mail.gmail.com>

On Fri, May 08, 2026 at 11:42:10AM +0200, Miklos Szeredi wrote:
> On Mon, 27 Oct 2025 at 23:39, Joanne Koong <joannelkoong@gmail.com> wrote:
> > Miklos, could you share your thoughts on this? Are you in favor of
> > disabling default strictlimiting? Or do you prefer to have it kept
> > enabled by default, with some mount option or sysctl added for
> > privileged servers to be able to disable strictlimiting + enable large
> > folios if they use the writeback cache?
> 
> So what I think we should do is implement some sort of slow writer
> test, and see what happens with and without strictlimit.
> 
> Tried to ask claude to do this for me, but not getting very far.
> 
> So if I take this maintainership role seriously and not let myself
> drown in the details, then the logical thing to do is to delegate ;)
> Which is hard (for me at least) but I'll give it a try...
> 
> Could you please check how things change if there's limited writeback
> rate and we disable strictlimit?  And what happens if there are
> several such instances running in parallel?

We have run all kinds of workloads and tests (xfstest, too) with 
writeback enabled and strictlimiting off.

I have not noticed any problems, but we have not done any systematic
tests regarding this. We were always testing something else.
(usually performance impacts)

Thanks,
Horst

  reply	other threads:[~2026-05-08 12:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-08 20:41 [PATCH] fuse: disable default bdi strictlimiting Joanne Koong
2025-10-09 14:16 ` Miklos Szeredi
2025-10-09 18:36   ` Joanne Koong
2025-10-10 15:01     ` Darrick J. Wong
2025-10-10 15:07       ` Matthew Wilcox
2025-10-10 23:14       ` Joanne Koong
2025-10-27 22:38     ` Joanne Koong
2026-05-08  9:42       ` Miklos Szeredi
2026-05-08 11:54         ` Horst Birthelmer [this message]
2026-05-12 20:56         ` Joanne Koong
2026-05-27  1:42           ` Joanne Koong
2026-05-27  5:57             ` Horst Birthelmer
2026-05-27 10:59               ` Amir Goldstein
2026-05-27 22:40                 ` Joanne Koong
2026-05-27 12:25             ` Miklos Szeredi
2026-05-27 23:32               ` Joanne Koong
2026-05-28 12:34             ` Jan Kara
2026-05-28 22:11               ` Joanne Koong
2026-05-30 11:04                 ` Jan Kara
2026-05-30  2:15             ` Joanne Koong

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=af3NyD5QDK6pmbR_@fedora.fritz.box \
    --to=horst@birthelmer.de \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=joannelkoong@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.