From: wangyufei <wangyufei@vivo.com>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
wangyufei <wangyufei@vivo.com>,
linux-kernel@vger.kernel.org (open list),
linux-mm@kvack.org (open list:MEMORY MANAGEMENT - MISC),
linux-fsdevel@vger.kernel.org (open list:PAGE CACHE)
Cc: kundan.kumar@samsung.com, anuj20.g@samsung.com, hch@lst.de,
bernd@bsbernd.com, djwong@kernel.org, jack@suse.cz,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, opensource.kernel@vivo.com
Subject: [RFC 0/1] writeback: add sysfs to config the number of writeback contexts
Date: Mon, 25 Aug 2025 20:29:29 +0800 [thread overview]
Message-ID: <20250825122931.13037-1-wangyufei@vivo.com> (raw)
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.
Our implementation supports *increasing* the number of writeback contexts.
This is achieved by dynamically allocating new writeback contexts and
replacing the existing bdi->wb_ctx_arr and bdi->nr_wb_ctx. But we have
not yet solved the problem of safely *reducing* the bdi->nr_wb_ctx.
Several challenges remain:
- How should we safely handle ongoing I/Os when contexts are removed?
- What is the correct way to migrate pending writeback tasks and related
resources to other writeback contexts?
- Should this be a per-device or global setting?
We're sharing this early implementation to gather feedback on:
1. Is runtime configurability of writeback contexts a worthwhile goal?
2. How should we handle synchronization and migration when dynamically
changing the bdi->nr_wb_ctx, particularly when removing the active
writeback contexts?
3. Any better tests to validate the stability of this approach?
We look forward to feedback and suggestions for further improvements.
[1] Parallelizing filesystem writeback :
https://lore.kernel.org/linux-fsdevel/20250529111504.89912-1-kundan.kumar@samsung.com/
[2] The discussion on configuration of the number of writeback contexts :
https://lore.kernel.org/linux-fsdevel/20250609040056.GA26101@lst.de/
wangyufei (1):
writeback: add sysfs to config the number of writeback contexts
include/linux/backing-dev.h | 3 ++
mm/backing-dev.c | 59 +++++++++++++++++++++++++++++++++++
mm/page-writeback.c | 61 +++++++++++++++++++++++++++++++++++++
3 files changed, 123 insertions(+)
--
2.39.0
next reply other threads:[~2025-08-25 12:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250825123009epcas5p1573496e2cad2f58d22036493e5af03be@epcas5p1.samsung.com>
2025-08-25 12:29 ` wangyufei [this message]
2025-08-25 12:29 ` [RFC 1/1] " wangyufei
2025-08-25 14:46 ` [RFC 0/1] " David Hildenbrand
2025-08-25 16:15 ` Matthew Wilcox
2025-08-29 8:59 ` Kundan Kumar
2025-09-02 11:19 ` wangyufei
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=20250825122931.13037-1-wangyufei@vivo.com \
--to=wangyufei@vivo.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=anuj20.g@samsung.com \
--cc=bernd@bsbernd.com \
--cc=david@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=kundan.kumar@samsung.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=opensource.kernel@vivo.com \
--cc=rppt@kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--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