Re: [PATCH v4 0/3] memcg,writeback: flush foreign bdev mappings separately

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 14 Sep 2026 18:31:16 +0800 Julian Sun <sunjunchao@bytedance.com> wrote:

> Bdev inodes are routinely shared by multiple memcgs. Recording their
> owner wb as foreign can cause dirty throttling in one memcg to trigger
> writeback of unrelated file data belonging to that wb.
> 
> On one production machine, bdev mapping snapshots showed as little
> as about 10 MiB of dirty data. A queue snapshot of its owner wb showed
> 599 foreign-flush works, with an average requested writeback budget of
> 43 GiB per work.
> 
> In other words, a small amount of foreign dirtying in the bdev mapping
> can trigger owner-wide writeback requests, whose budgets averaged
> 43 GiB in this queue snapshot.

What is the overall runtime effect of this?  IOW, can we see some
before-and-after numbers?

> Following Jan's suggestion, this series records foreign bdev targets
> separately and flushes their mappings instead of their owner wbs. This
> preserves a way for dirty throttling to initiate bdev writeback while
> avoiding owner-wide writeback triggered by these records. The existing
> foreign-wb mechanism remains unchanged for other inodes.
> 
> Tracking is best effort: each memcg keeps a bounded set of device
> numbers without persistent device or inode references. Closed devices
> and devices with a busy open_mutex are skipped. Device removal and
> device-number reuse may race with lookup.
> 
> Flushes run asynchronously on a dedicated workqueue to isolate these
> frequently triggered tasks from existing workqueue users. If workqueue
> allocation fails, the existing foreign-wb mechanism remains in use.
> 
> Julian Sun (3):
>   block: introduce bdev_flush_by_dev()
>   memcg,writeback: flush foreign bdev mappings separately from owner wbs
>   writeback: record bdev targets in foreign writeback tracepoints
> 
>  block/bdev.c                     |  24 +++++++
>  include/linux/blkdev.h           |   1 +
>  include/linux/memcontrol.h       |  15 ++++
>  include/trace/events/writeback.h |  22 +++---
>  mm/memcontrol.c                  | 113 ++++++++++++++++++++++++++++---

I'd consider this a memcg patch, and not only due to the line counts.

Please cc linux-mm on memcg patchsets.