[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aKyMPH92SfYZcCM2@casper.infradead.org>
Date: Mon, 25 Aug 2025 17:15:56 +0100
From: Matthew Wilcox <willy@...radead.org>
To: David Hildenbrand <david@...hat.com>
Cc: wangyufei <wangyufei@...o.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Michal Hocko <mhocko@...e.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
open list <linux-kernel@...r.kernel.org>,
"open list:MEMORY MANAGEMENT - MISC" <linux-mm@...ck.org>,
"open list:PAGE CACHE" <linux-fsdevel@...r.kernel.org>,
kundan.kumar@...sung.com, anuj20.g@...sung.com, hch@....de,
bernd@...ernd.com, djwong@...nel.org, jack@...e.cz,
opensource.kernel@...o.com
Subject: Re: [RFC 0/1] writeback: add sysfs to config the number of writeback
contexts
On Mon, Aug 25, 2025 at 04:46:46PM +0200, David Hildenbrand wrote:
> On 25.08.25 14:29, wangyufei wrote:
> > Hi everyone,
> >
> > We've been interested in this patch about parallelizing writeback [1]
> > and have been following its discussion and development. Our testing in
> > several application scenarios on mobile devices has shown significant
> > performance improvements.
> >
> > Currently, we're focusing on how the number of writeback contexts impacts
> > the performance on different filesystems and storage workloads. We noticed
> > the previous discussion about making the number of writeback contexts an
> > opt-in configuration to adapt to different filesystems [2]. Currently, it
> > can only be set via a sysfs interface at system initialization. We'd like
> > to discuss the possibility of supporting dynamic runtime configuration of
> > the number of writeback contexts.
> >
> > We have developed a mechanism that allows the number of writeback contexts
> > to be configured at runtime via a sysfs interface. To configure, use:
> > echo <nr_wb_ctx> > /sys/class/bdi/<dev>/nwritebacks.
>
> What's the target use case for updating it dynamically?
>
> If it's mostly for debugging/testing (find out what works, what doesn't), it
> might better go into debugfs or just carried out of tree.
>
> If it's about setting sane default based on specific filesystems, maybe it
> could be optimized from within the kernel, without the need to expose this
> to an admin?
I was assuming that this patch is for people who are experimenting to
gather data more effectively. I'd NAK it being included, but it's good
to have it out on the list so other people don't have to reinvent it.
Powered by blists - more mailing lists