From: Tejun Heo <tj@kernel.org>
To: Julian Sun <sunjunchao@bytedance.com>
Cc: linux-block@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
axboe@kernel.dk, hannes@cmpxchg.org, mhocko@kernel.org,
roman.gushchin@linux.dev, shakeel.butt@linux.dev,
muchun.song@linux.dev, willy@infradead.org, jack@suse.cz,
tj@kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH v7 2/3] memcg,writeback: flush foreign bdev mappings separately from owner wbs
Date: Mon, 21 Sep 2026 07:55:17 -1000 [thread overview]
Message-ID: <b15c63490f9164bf46d68ff3ec5dfc02@kernel.org> (raw)
In-Reply-To: <20260921120658.1627992-3-sunjunchao@bytedance.com>
Hello, Julian.
This is an AI review. The series was built here, and the bdev reference
across a racing last close and disk removal, the slot races, and the
css_free ordering were traced and look correct. Two behavioral notes and
some description and comment fixups.
On Mon, Sep 21, 2026 at 08:06:57PM +0800, Julian Sun wrote:
> Use fixed per-memcg slots. Tracking is best effort: record only dev_t
The slot policy this version adopted, oldest-first replacement, expiry
after dirty_expire_interval, and re-arming when the mapping is dirtied
while a flush is in flight, isn't stated anywhere. Can you add a sentence?
> If allocation fails, retain the existing foreign-wb path.
Andrew found this unclear on v6 and the subject is still implied. Something
like "If the workqueue can't be allocated at boot, bdev inodes keep using
the existing foreign-wb path."?
> This primarily affects filesystems that keep metadata in the bdev page
> cache, such as ext4 and other buffer_head users, rather than the usual
The branch keys on sb_is_blkdev_sb(), so buffered writers of raw block
devices are covered too whenever the bdev inode's wb belongs to another
cgroup. Worth a mention.
> +struct bdev_frn_flush_ctx {
> + struct work_struct work;
> + dev_t dev; /* for bdev inode, device hint */
> + u64 at; /* last recorded dirtying time in jiffies */
> + atomic_t inflight;
> +};
It sits next to memcg_cgwb_frn and is memcg's, so maybe memcg_bdev_frn?
"for bdev inode, device hint" doesn't say what the value is. Following the
sibling's comments, "dev_t of the foreign bdev inode", and @inflight could
use one too.
> + * For non-bdev inodes, when a foreign page - a page whose memcg and
> + * writeback ownerships don't match - is dirtied,
> + * mem_cgroup_track_foreign_dirty() records the inode owning bdi_writeback
> + * on the page owning memcg. When balance_dirty_pages() decides that the
> + * memcg needs to sleep due to high dirty ratio, it calls
> * mem_cgroup_flush_foreign() which queues writeback on the recorded
> * foreign bdi_writebacks which haven't expired. Both the numbers of
> * recorded bdi_writebacks and concurrent in-flight foreign writebacks are
> * limited to MEMCG_CGWB_FRN_CNT.
The flush sentence and the slot limit apply to both paths now, so the "For
non-bdev inodes" scoping reads wrong. Maybe keep the original paragraph and
let the new one state only the difference: separate MEMCG_CGWB_FRN_CNT
slots keyed by dev_t, flushing only the bdev mapping, same expiry.
> + * These wb/bdev_inodes records only remember IDs and don't hold any object
> + * references. As being wrong occasionally doesn't matter, updates and
> + * accesses to the records are lockless and racy.
The paragraph above already says the bdev records hold no references, and
"wb/bdev_inodes records" doesn't parse. "Both kinds of records only
remember IDs ..." would do.
> + if (memcg_bdev_frn_wq && bdev_inode &&
> + sb_is_blkdev_sb(bdev_inode->i_sb)) {
> + mem_cgroup_track_foreign_bdev(memcg, bdev_inode->i_rdev);
> + return;
> + }
>
> trace_track_foreign_dirty(folio, wb);
With this patch alone, foreign dirtying of a bdev folio no longer hits
track_foreign_dirty at all and patch 3 adds the call back inside the
branch. Can you keep the tracepoint firing on the bdev path here so that
patch 3 only adds the argument? Also, @bdev_inode can't be NULL:
__folio_mark_dirty() checked folio->mapping under the same lock and
folio_account_dirtied() already dereferenced mapping->host.
> +static void bdev_frn_flush_work(struct work_struct *work)
> +{
> + struct bdev_frn_flush_ctx *ctx =
> + container_of(work, struct bdev_frn_flush_ctx, work);
> +
> + bdev_flush_by_dev(ctx->dev);
> +
> + atomic_set(&ctx->inflight, 0);
> +}
The in-flight window is now just the submission of the bdev mapping, and
mem_cgroup_flush_foreign() runs on every throttle-loop iteration, so a
memcg that keeps dirtying and throttling requeues the flush back to back.
A folio the flush redirties, e.g. a buffer locked by a jbd2 checkpoint
write, re-stamps the slot on its own. The old record stayed in flight for
the whole owner-wb work. With a journal the write cadence of hot metadata
is still bounded by the commit interval, but for nojournal ext4 and other
buffer_head users it's bounded only by the throttle pause, for every
tenant of the filesystem while any tenant throttles. Not measured. The
description covers the target size but not the cadence.
Each pass also goes through wbc_attach_fdatawrite_inode() and
wbc_detach_inode(), so it votes in the bdev inode's wb-switch detection
like the owner-wb flush did, at the higher pass rate. Whether the bdev
inode ends up switching wbs more often is an open question.
> + if (memcg_bdev_frn_wq && time_after64(ctx->at, now - intv) &&
> + atomic_cmpxchg(&ctx->inflight, 0, 1) == 0) {
Records are only created when the workqueue exists and @at stays 0
otherwise, so the wq test can't be false with a live record. Fine as
documentation, but the cover lists it as a fix.
> + INIT_WORK(&ctx->work, bdev_frn_flush_work);
> + atomic_set(&ctx->inflight, 0);
memcg is zero-allocated, so the atomic_set() isn't needed.
On patch 1, the kerneldoc's "does not wait for all I/O to complete"
understates it, the flush waits for nothing.
Thanks.
--
tejun
next prev parent reply other threads:[~2026-09-21 17:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 12:06 [PATCH v7 0/3] memcg,writeback: flush foreign bdev mappings separately Julian Sun
2026-09-21 12:06 ` [PATCH v7 1/3] block: introduce bdev_flush_by_dev() Julian Sun
2026-09-21 12:06 ` [PATCH v7 2/3] memcg,writeback: flush foreign bdev mappings separately from owner wbs Julian Sun
2026-09-21 17:55 ` Tejun Heo [this message]
2026-09-22 9:52 ` Julian Sun
2026-09-21 12:06 ` [PATCH v7 3/3] writeback: record bdev targets in foreign writeback tracepoints Julian Sun
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=b15c63490f9164bf46d68ff3ec5dfc02@kernel.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=sunjunchao@bytedance.com \
--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