[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9cb4adf8-94c7-4fa0-8bed-2f9274969b48@redhat.com>
Date: Mon, 25 Aug 2025 16:46:46 +0200
From: David Hildenbrand <david@...hat.com>
To: 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>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
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>
Cc: 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 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?
--
Cheers
David / dhildenb
Powered by blists - more mailing lists