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

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

On Tue, 15 Sep 2026 13:35:18 +0800 Julian Sun <sunjunchao@bytedance.com> wrote:

> > 
> > What is the overall runtime effect of this?  IOW, can we see some
> > before-and-after numbers?
> 
> I tested this series using a QEMU/KVM VM with 4 vCPUs, 8 GiB RAM,
> cgroup v2 and ext4. Virtual NVMe write bandwidth was capped at
> 200 MiB/s.
> 
> A fio job repeatedly overwrote a preinitialized 256 MiB file using
> 64 KiB buffered writes, at 64 MiB/s, for 9 GiB of logical writes.
> Four memcgs, each with memory.high=32 MiB and io.max=2 MiB/s, generated
> metadata and buffered writes to trigger dirty throttling and foreign
> flushes. Concurrently, foreground fio performed 16 GiB of sequential
> direct writes using 1 MiB requests and queue depth 32. Normal periodic
> writeback remained enabled.
> 
> Three comparison pairs, with alternating execution order, produced:
> 
> Run  Kernel   File I/O (GiB)  Time (s)  BW (MiB/s)  p99 (ms)
> 1    base              7.19    114.74      142.79      1434
> 1    patched           1.57     88.62      184.87       480
>       change         -78.22%   -22.76%     +29.47%   -66.52%
> 
> 2    base              5.13    103.59      158.16      1434
> 2    patched           1.74     88.65      184.81       497
>       change         -66.06%   -14.42%     +16.85%   -65.35%
> 
> 3    base              6.14    109.27      149.94      1434
> 3    patched           1.73     88.68      184.75       480
>       change         -71.77%   -18.85%     +23.22%   -66.52%
> 
> File I/O is completed block I/O matching the overwritten file's extents,
> including final sync, not requested writeback budgets. The other metrics
> are for the foreground workload.
> 
> Across these runs, mean file write I/O decreased by 72.7%, foreground
> bandwidth increased by 23.0%, and completion time decreased by 18.8%.

Thanks.  This is super-important info so please condense, summarize and
emphasize this result in the [0/N].

How real-world is this test case?  I assume people won't see gains like
this in anything they normally do?  I assume this is long-standing
behavior, so if misbehavior like this was regularly being observed then
we'd have fixed it by now.

> > 
> > I'd consider this a memcg patch, and not only due to the line counts.
> > 
> > Please cc linux-mm on memcg patchsets.
> Sure, will do.

Great.  Please update that [0/N] as indicated - help readers understand
the expected real-world impacts.  Then send us a v5 and I'll get to
work helping to deliver this to our users.