Re: [PATCH v2] writeback: size foreign flushes by target wb dirty pages

[Liz Fong-Jones]

On Thu, Sep 24, 2026 at 02:54:43PM +0800, Xin Yin wrote:
> Use the target wb's WB_RECLAIMABLE counter and keep the existing 25%
> headroom.

At Honeycomb, a container that reads from Kafka and writes columnar
files to a host volume stalls for 30-60s after each deploy replaces it
(v6.18). This is likely the cause: the stall looks the same as in our
reproducer (little CPU use, lag growing linearly and then recovering),
though we haven't traced it in production yet.

I tested with a reproducer where one cgroup appends to 1000 files at
250MiB/s and stops, then a sibling keeps appending to the same files
under a 4G parent limit. With the old cgroup kept alive, worst lag
behind schedule over 120s, three runs each, arm64 KVM guest:

  b53f422491af (parent)  9.4s  3.0s  10.7s
  168a8c13159c           1.0s  1.1s   1.1s

Tested-by: Liz Fong-Jones <lizf@xxxxxxxxxxxx>

When the old cgroup is removed, which is what a restart does, this patch
alone doesn't help: wb_get_lookup() can't find the dying wb, so the
flush fails with -ENOENT before the sizing matters. My follow-up fixes
the lookup. Worst lag in each run, this patch alone and with the
follow-up on top:

                                       this patch         + follow-up
  old cgroup removed, 1000 files       85.3  46.9  52.1s  1.1  1.0  1.1s
  500k files, synced before removal   115.3 115.3s        1.5  1.0s
  500k files, pod cgroup removed too  115.9  47.5s        1.0  1.0s

  https://lore.kernel.org/all/20260926-wb-dying-cgwb-flush-v1-1-a8d898085a3a@xxxxxxxxxxxx/

Christian, could this one get Cc: stable as well? Both bugs date back
to v5.4.

Debugged with Claude Opus 5.5, which ran the tests; I designed the
experiments and reviewed the results.

Thanks,
Liz