Re: [PATCH v3] cgroup: avoid flushing global workqueue in cgroup1_pidlist_destroy_all

[Tejun Heo]

Hello,

On Wed, Sep 09, 2026 at 04:46:19PM +0800, Junnan Zhang wrote:
> Would you consider taking it as a minimal fix? Or, if the consensus
> is to leave v1 completely untouched, what would be the recommended
> course for production systems that keep hitting this?

The problem is that the root cause isn't sufficiently established. It's just
difficult to believe cleaning up these lists would take longer than 120s in
itself. Maybe there were other contributing factors - e.g. another
saturating per-cpu work item that was preventing the execution of the
pidlist work item, high memory pressure stalling worker creation, or just
severe CPU contention from bw control or whatnot.

Without the root cause convincingly established, this can't be a "minimal
fix". This can be a proactive behavior improvement, but that's not something
we want to do for cgroup1 code base at this point. Not because we hate
people on cgroup1 but because they're the legacy users on legacy code base.
Nobody is actively working on it and no leading edge testing and adoption
covers it. Any change carries risk of breakage and a change like this can
lead to really subtle problems that can take a long time to diagnose
especially with slow-moving long-tail userbase.

So, yes, I'll take minimal fixes that address real problems (subject to risk
vs. benefit balance of course), but you haven't established that yet.

Thanks.

-- 
tejun