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

On Thu, 17 Sep 2026 14:57:56 +0800 Julian Sun <[email protected]> wrote:

> Hi,
> 
> This series avoids owner-wide foreign writeback triggered by dirtying
> shared bdev inodes. Instead, it tracks bdev targets separately and
> schedules writeback of their mappings.
> 
> Problem
> =======
> 
> Bdev inodes are commonly shared by many memcgs. Dirtying their pages
> can cause the owner wb to be tracked as foreign, triggering writeback
> of the entire wb rather than just the bdev mapping.
> 
> In production, almost all the foreign dirtying we traced came from bdev
> inodes. Across our observations, a bdev mapping had as little as about
> 10 MiB of dirty pages, yet foreign flushes targeted the entire owner
> wb. On one machine, we observed 599 such works queued on one wb, with
> an average request budget of about 43 GiB per work.
> 
> Measured impact
> ===============
> 
> The synthetic test used a VM with 4 vCPUs, 8 GiB RAM, ext4 and cgroup
> v2, with device write bandwidth capped at 200 MiB/s. Background fio
> repeatedly overwrote a 256 MiB file using buffered I/O, while
> foreground fio performed sequential direct writes. Four memcgs
> generated metadata and buffered writes to trigger foreign flushes.
> 
> We measured completed block writes to the background fio file,
> including final sync, and foreground fio bandwidth, latency and
> completion time.
> 
> Across three runs per kernel, mean background file write I/O decreased
> by 72.7%, foreground bandwidth increased by 23.0%, and completion time
> decreased by 18.8%.
> 
> Metric                         Baseline    Patched     Change
> Background file write I/O (GiB)    6.154      1.680     -72.7%
> Foreground bandwidth (MiB/s)      150.29     184.81     +23.0%
> Foreground completion time (s)   109.203     88.652     -18.8%
> Foreground mean latency (ms)      212.84     172.74     -18.8%

Thanks.

As I understand it, this is basically ext4-specific.

I don't think btrfs or xfs mess with the bdev address_space at all? 
But google tells me that "roughly 70% to 80% of all Linux machines use
ext4 as their primary or root file system", so there is that.

> Approach
> ========
> 
> 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.

This part looks plain nasty.  Why are we messing with dev_t's and
risking these races?

At the very least, this description should explain the reasoning behind
this decision at some length.

Surely it's cleaner and safer to grab a ref on something (the bdev
inode?) and hang onto that object.  Use it for these operations, let it
go at the appropriate time.  Clearly there's something wrong with that
approach, but what?

> 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.

Unclear what this means.  If a kmalloc/etc fails then we fall back to
the current (mainline) behavior?  Fair enough, failure of small
kmallocs are so rare.  The main problem is testing the failure-path
code!


Also, and most importantly, what the heck is "frn"?  Would the world
end if you did s/frn/foreign/g?