On Fri, Sep 30, 2022 at 02:18:56PM +0200, Michal Koutný wrote:
> On Fri, Sep 30, 2022 at 08:20:06AM +1000, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> > Fixes: b3ff92916af3 ("mm, memcg: reclaim more aggressively before high allocator throttling")
>
> Perhaps you meant this instead?
>
> Fixes: c9afe31ec443 ("memcg: synchronously enforce memory.high for large overcharges")
You might be right in that c9afe31ec443 exposed the issue, but it's
not the root cause. I think c9afe31ec443 just a case of a
new caller of mem_cgroup_handle_over_high() stepping on the landmine
left by b3ff92916af3 adding an unconditional GFP_KERNEL direct
reclaim deep in the guts of the memcg code.
IOWs, if b3ff92916af3 did things the right way to begin with, then
c9afe31ec443 would not have caused any problems. So what's the real
root cause of the issue - the commit that stepped on the landmine,
or the commit that placed the landmine?
Either way, if anyone backports b3ff92916af3 or has a kernel with
b3ff92916af3 and not c9afe31ec443, they still need to know
about the landmine in b3ff92916af3....
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
