From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0FD35D68BE3 for ; Thu, 18 Dec 2025 06:55:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D9F66B0089; Thu, 18 Dec 2025 01:55:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 387516B008A; Thu, 18 Dec 2025 01:55:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 268F36B008C; Thu, 18 Dec 2025 01:55:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 121526B0089 for ; Thu, 18 Dec 2025 01:55:58 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 99737140D33 for ; Thu, 18 Dec 2025 06:55:57 +0000 (UTC) X-FDA: 84231681954.13.E2D543E Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf27.hostedemail.com (Postfix) with ESMTP id C1E8B4000C for ; Thu, 18 Dec 2025 06:55:55 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kl+IXhGS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of kdipendra88@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=kdipendra88@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1766040955; a=rsa-sha256; cv=none; b=a1aTxQ6xjjp/fYnZb0FNEKebAD+U3xjMg+S6/q1MLDmkUOAmCXmoZ1u3xgAXmsjRJeS1AR SoORnAW6QU3R/w6jtaVy4aTxOrTslzzVvL6kSPFYpAsxfEuyrzgxR1dBzziNSzL+zwjaKD 32FlP92D1pnShFE0DXZJaMDUraTDhX8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kl+IXhGS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of kdipendra88@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=kdipendra88@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1766040955; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yC7n9Z0OzYbxwInXF7xKv9suG/5p2FgSxK43erIupu4=; b=ed+VXhK+th3mybVWSGBo4Pmqw6YPwxDdaJT3m/QlwkbfzP8/yfntujCAfcCbG3LJ5OGfYK 60KLasCk4b+CfX9iYQy85ZGvdZNXPGrm6jxdVotBP1acC0ZxY01xZvHgaVOvHWe3sbHq05 aLsizFESLfr7WSuywA4S/OYo0Vu97xU= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-55999cc2a87so59978e0c.0 for ; Wed, 17 Dec 2025 22:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766040955; x=1766645755; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yC7n9Z0OzYbxwInXF7xKv9suG/5p2FgSxK43erIupu4=; b=kl+IXhGS4x+dpEYw9k+HJA1QMMDA3+BBTFWM+kAgLFrXJbnukhVpKgUx38M2v0yzd3 IqAB9SBnvwkHdnkrz5w+8G+sbwgsc+BGvSjp2afSK79WuIPHoHtp/rh150gdqSJxJphQ /3VcWYjQbO6AlIiO+6jl4jTLz+eOrKV2zsaZ4ZHhoYMNEkNpvA0kXl08lU7qVhG+RT7U cMJDru0A7BNUI+5D54qtyEu4ta2UnmfsUo/OkYfyFCAXD290QzsHIhcAMpP4FlLArBZU l6cPWGORGeldYrCWgNVGdUWsBMaFOziH6ktjvRUmB2o5Pegh21EyoCiinjF9alu/VuEL jSrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766040955; x=1766645755; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yC7n9Z0OzYbxwInXF7xKv9suG/5p2FgSxK43erIupu4=; b=fKFcJkhL/o8OK2pCMUKdIKLa/KfiaH2hY8rxcoyIybCKWrEs2d3qv7piqw1Zk/AKpj z+ut570oLJbeuchPSmYEq2Zon2uLGa2kboHyqfl3P2hNI0p1VCTGWJn1r5+uoqz2RBnX 2IjmWo3JiL0igMPp7o37N+amw1nMiTU9JG2IIqadgvj1/E8XRLFMVx+0p5KYifdA9Esa IwXwg6CVF6vfUTXDVQ0aviJQ5AedYB9Iq0ej3MKEKEvnG8yQzmQE9dc/REFwckA2lVMr giYLtHjO4FA32xhszoUZYLlXXHbiQy2MyNLDKL0l6kUZwT6l7DYf5yt28ungWKdHC3Q9 OYag== X-Forwarded-Encrypted: i=1; AJvYcCVsu0tC6DoQ+PjO7mgCG7mq4Ft7nUOpqKVOXNJ7kl8NX1t7PLl2v34r/sNs2gRit1Z08gTPOWp85A==@kvack.org X-Gm-Message-State: AOJu0Yx+99Mt5ZsoP4ieM70f5aeHJgNCidYle7zZ+k5u8mq+MWOUFbcP YEv7vVDSCoz+BVBKl2EPkijK/Y1UmK/V06d+AD9MPirW/pdgxXXzEPLuHhST1IINR4NfKFDFyAW EkQf7cACm0mxuS7f8AIXyHe+pdhJgubc= X-Gm-Gg: AY/fxX6EvFd8wdKm6qBisEGEHsbJUHLDz5czNSFP/GUxPtfXRI+gUslja3YRTpSu5H7 sWbBPS3QvF/+VCSXBSkZsrkC1oVc+eChSJUYE38YaLfRWO6JH+2OKfW1IRHCTscCWVCMb9rsokv W2loJt6sh0x+gZ4K1csjvLSHAxKtfKSMA86Z///WnLREo0bK1KJ2YfTLLgELPeS+RHDdXAi6mhj wnuX38Wx5z36BCf8ryNtw/VC41mFFg2F0HP5AkTht8T35hVKa4kvCX5uXJlFc7HZhLoqhg+tgpN ArFRew== X-Google-Smtp-Source: AGHT+IHGfC1PW6ElJj42hBmYMvkBJBTPLHZU0nYuWISQSY5DPEpuUErQKpdAAKn/kt4MjBsfyYd7os0EWdEa3LQr6sE= X-Received: by 2002:a05:6122:2205:b0:55b:305b:4e3f with SMTP id 71dfb90a1353d-55fed6818c4mr7173545e0c.21.1766040954677; Wed, 17 Dec 2025 22:55:54 -0800 (PST) MIME-Version: 1.0 References: <20251215145419.3097-1-kdipendra88@gmail.com> <20251215204624.GE905277@cmpxchg.org> In-Reply-To: <20251215204624.GE905277@cmpxchg.org> From: Dipendra Khadka Date: Thu, 18 Dec 2025 12:40:45 +0545 X-Gm-Features: AQt7F2o679XFZgDON1prz6S8WwlSLI1JYKT-mJ-iMhmtOGoRxRlJzEJuPCEHhro Message-ID: Subject: Re: [PATCH] mm/memcg: reorder retry checks for clarity in try_charge_memcg To: Johannes Weiner Cc: akpm@linux-foundation.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: multipart/alternative; boundary="000000000000c32e250646347369" X-Rspamd-Queue-Id: C1E8B4000C X-Rspamd-Server: rspam03 X-Stat-Signature: 3rz7kracz81pfesuonbm6cap4xjith87 X-Rspam-User: X-HE-Tag: 1766040955-471387 X-HE-Meta: U2FsdGVkX1+T64gRMWw5YwxNPV5rDHvA2xDGxhEvRUI04RJNsffh8d0nH7l+b7MSMbtgIxqGHbVVh82OLMZEMF+wzRIiLkkRDHF+8cP5MCQTqZzB678TOjvnvuWrBtuWk0xIUGdkZrW4iBaQ5YpNA4iZVnGeYoL45VpcbBigv/8rFQ/jdSs/aS8ePOx3Et9Oe+w2gjy5O0P1SuKMZLcQAk824cIJbPh5cXSwBnRW3QRQdOUBdJmZ5rkHQSgGUCk79QSavNTvB3ScIoDD/jsEd8En1rrgrFjMpDMrO8xdVbr/RDlmgjg9vyL13qFahY1nGFO7oq6rPVh1Yc5nPrcXJqBMWW+pp24pMXfeNwQ+pIXqMSijXvuoPUZtKfpDPZ5kS0GVlfNzYGY5cLF9Ym/bir4lyZsCpOz1ka/jTrfKCH9ct6hzl1qwrES7F9Auxhuz0XshQXU1+whtX1Q9x9SLh7D+gt87AbACTRRH1sB8xPKrKkgWJMoeJBYGZ0dqO8ZW7MjNjhZjIGGLM1MaAuaS3yUOQDYUoTiOQGSFkzYfhMxX9BWIewHFCjXiqv5sd/4kX+EQj6knbtO2C9clumCGLARbcHD4l59V3C7M0rnjmHKADcN3d5KAoNxCvok9XMKqoZIFd8U2QMcuR5KXYhdOhvJPCmahZ3B7G4VdqGbzC5MHq2VCScm6Uhq5UAbbKeBNULTLO/N9PIpMWGnSXbNCLToGumIU8em4f8gCGjo5TC/Ybwfe4AR+QneHpFHyzZGhzSGg07jNGWxEomPtjDlz7q0wRb4o/vVbMDqUi7h+32S6eQRj8vjO2qEi6oK0UwpIMuNhXWwqoQpqjRa46N09e/ncejGSo7gs/8bZkBjVtDuYQ5OwApmvX9b/+WLxYvfOjlAM4qvCbuOCiGr9crXTZUpCNTncbqSCip0GtHShtfLynYX+o0z8j+qaqwA9cpNOogfyUkZveKUzdWKjPTS ALcY0cxc COIDMHJZhblI9TVchIhfzXBv+4C8qBHjsU4NAefYoSUSI85sSK17wco1LzF9RE6j7JTPJY4wYJQpZZbzIysU7BWtjlme/+yTDpTxGIoWCl1jJqO94bsURla6P8oIH3TgHj1haWdLLsR67iLLJRJjVC01HIwGxYQa8ha7Kmc5iu9x7SFBQd4Yph0kHMIznKds0hIq+6MPSV+scZ14b8VkCLvS0Agfgr8FLo0ur1vcC2SwbAY4LHCOPbD2OWQRYgVva/ijXgS1/cUdV0g1/Yiigzqd8yqwfYeok2teTXWTsFmwtNkGgnxdOBgx1qxf/Cl3U56PiqzzPYldutTdYwiCHX0PN46aQW2q1gd0+5/hGOpNyMozY6S8cB4WbHO+2TpJyBKny+r1m8ZITRwaWJiLYoqiSww7g8ES/T1rtZupeJkPIIWwuQOiSFNNwzQgtRrWd1as+VbdD7fBKTNUGl1ePAeFadulZk1nUOJR9sDOeN6iyuGKUk4HltdB7FvRUiWoRV2Fq3OYQ9KG3tXXjY1aPyChPne0e+h/YTyEoLz5eEJrYGNFi4JSbsy1UMd+7VAcaRBAQ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --000000000000c32e250646347369 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Johannes, On Tue, 16 Dec 2025 at 02:31, Johannes Weiner wrote: > On Mon, Dec 15, 2025 at 02:54:19PM +0000, Dipendra Khadka wrote: > > In try_charge_memcg(), reorder the retry logic checks to follow the > > early-exit pattern by testing for dying task before decrementing the > > retry counter: > > > > Before: > > if (nr_retries--) > > goto retry; > > > > if (passed_oom && task_is_dying()) > > goto nomem; > > > > After: > > if (passed_oom && task_is_dying()) > > goto nomem; > > > > if (nr_retries--) > > goto retry; > > > > This makes the control flow more obvious: check exit conditions first, > > then decide whether to retry. When current task is dying (e.g., has > > received SIGKILL or is exiting), we should exit immediately rather than > > consuming a retry count first. > > > > No functional change for the common case where task is not dying. > > It's definitely a functional change, not just code clarification. The oom kill resets nr_retries. This means that currently, even an OOM > victim is going to retry a full set of reclaims, even if they are > hopeless. After your patch, it'll retry for other reasons but can bail > much earlier as well. Check the other conditions. > The dying task / OOM victim allocation path is tricky and it tends to > fail us in the rarest and most difficult to debug scenarios. There > should be a good reason to change it. > Thank you for the feedback. Let me clarify the scenario this patch addresse= s : The task_is_dying() check in try_charge_memcg() identifies when the CURRENT task (the caller) is the OOM victim - not when some other process was killed. Two scenarios: 1. Normal allocator triggers OOM: - Process A allocates =E2=86=92 triggers OOM - Process B is killed (victim) - Process A continues with reset retries - task_is_dying() =3D false for = A =E2=86=92 Unchanged by my patch 2. Victim tries to allocate: - Process B (victim, TIF_MEMDIE set) tries to allocate - task_is_dying() =3D true - Current code: wastes retries on hopeless reclaims - My patch: exits immediately =E2=86=92 Optimization for this case The victim has three safety mechanisms that make the retries unnecessary: 1. oom_reaper proactively frees its memory 2. __alloc_pages_slowpath() grants reserves via oom_reserves_allowed() 3. Critical allocations with __GFP_NOFAIL still reach force: label The retry loop for a dying victim is futile because: - Reclaim won't help (victim is being killed to free memory!) - Victim will exit regardless - Just wastes CPU cycles Best Regards, Dipendra --000000000000c32e250646347369 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Johannes,


<= div class=3D"gmail_quote gmail_quote_container">
On Tue, 16 Dec 2025 at 02:31, Johannes Weiner <hannes@cmpxchg.org> wrote:
On Mon, Dec 15, 2025 at 02:54:19P= M +0000, Dipendra Khadka wrote:
> In try_charge_memcg(), reorder the retry logic checks to follow the > early-exit pattern by testing for dying task before decrementing the > retry counter:
>
> Before:
>=C2=A0 =C2=A0 =C2=A0if (nr_retries--)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto retry;
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0if (passed_oom && task_is_dying())
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto nomem;
>
> After:
>=C2=A0 =C2=A0 =C2=A0if (passed_oom && task_is_dying())
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto nomem;
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0if (nr_retries--)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto retry;
>
> This makes the control flow more obvious: check exit conditions first,=
> then decide whether to retry. When current task is dying (e.g., has > received SIGKILL or is exiting), we should exit immediately rather tha= n
> consuming a retry count first.
>
> No functional change for the common case where task is not dying.

It's definitely a functional change, not just code clarification.
=C2=A0
The oom kill resets nr_retries. This means that currently, even an OOM
victim is going to retry a full set of reclaims, even if they are
hopeless. After your patch, it'll retry for other reasons but can bail<= br> much earlier as well. Check the other conditions.

The dying task / OOM victim allocation path is tricky and it tends to
fail us in the rarest and most difficult to debug scenarios. There
should be a good reason to change it.

T= hank you for the feedback. Let me clarify the scenario this patch=20 addresses:=C2=A0

The task_is_dying() check in try_charge_memcg() identifies when the=C2=A0
= =C2=A0CURRENT t= ask (the caller) is the OOM victim - not when some other=20 process was killed.=C2=A0

Two scenarios:=C2=A0

1. Normal allocator triggers OOM:=C2=A0
=C2=A0 - Process A allocates =E2=86=92 = triggers OOM=C2=A0
=C2=A0 - Process B is killed (victim)=C2=A0
=C2=A0=C2=A0- Process = A continues with reset retries - task_is_dying() =3D false for A=C2=A0
=C2=A0 =E2=86=92 Unchanged by my patch=C2=A0

=C2=A02. Victim tries to allocate:
=C2=A0- Process B (v= ictim, = TIF_MEMDIE set= ) tries to allocate=C2=A0
=C2=A0 - task_is_dying() =3D true=C2=A0
=C2=A0 - Current code<= span class=3D"gmail-token" style=3D"color:rgb(97,175,239)">: wastes = retries on hopeless reclaims=C2=A0
=C2=A0 - My patch: exits immediately=C2=A0
=C2=A0 =E2=86=92 Optimization for this case=C2=A0

=C2= =A0The victim has three safety mechanisms that make the retries=20 unnecessary:=C2=A0
1. oom_reaper proactively frees its memory=C2=A0
2. __alloc_pages_slowpat= h() gra= nts reserves via oom_reserves_allowed()=C2=A0
3. Critical allocations with __GFP_NOFAIL still = reach force: label=C2=A0

The retry loop for a dying victim is fut= ile because:=C2=A0
- Reclaim won't help (victim is being killed to free memory!)=C2=A0
- Victim will exit= regardless=C2=A0
- Just wastes CPU cycles=C2=A0

=C2=A0Best Regards,
=C2=A0Dipendra
--000000000000c32e250646347369--