Re: [PATCH 3/3] memcg: bail out proactive reclaim when memcg is dying

[Jiayuan Chen]

On 6/24/26 9:58 PM, Usama Arif wrote:
> On Tue, 23 Jun 2026 14:27:56 +0800 Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
>
> > From: Jiayuan Chen <jiayuan.chen@xxxxxxxxxx>
> >
> > Proactive reclaim via memory.reclaim can run for a long time - swap I/O
> > or thrashing again dominating the latency - and delays cgroup removal in
> > the same way.
> >
> > Mitigate this by stopping the reclaim once memcg_is_dying().
> >
> > Reported-by: Zhou Yingfu <yingfu.zhou@xxxxxxxxxx>
> > Cc: Jiayuan Chen <jiayuan.chen@xxxxxxxxx>
> > Signed-off-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxxx>
> > ---
> >   mm/vmscan.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 8190c4abec84..1162b7f76655 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -7922,6 +7922,9 @@ int user_proactive_reclaim(char *buf,
> >   		if (memcg) {
> >   			unsigned int reclaim_options;
> >   
> > +			if (memcg_is_dying(memcg))
> > +				break;
> > +
> This exits the reclaim loop with nr_reclaimed < nr_to_reclaim, but the
> function then returns 0 and memory_reclaim() reports a successful write.
> I think you want to return -EAGAIN here?


You are right that an error should be returned instead of 0.


But since memcg is being deleted, I'm reconsidering the appropriateerror 
code.

-EAGAIN, -ENOENT, -EINTR are possible candidates