From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 50105324B1C for ; Mon, 15 Dec 2025 20:46:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765831592; cv=none; b=gWf1BRDrCT/rLPaL8Eub3UKY5uQvADtNzNjN7bpb0nquNZuYpKKJkJrGNSVS+JrJusgK+Y9hz2Cr0+eTVcMJ8BzX6xLaVpE25g4DwXELiuMtAr2xBwZCBlw/uhz5CmFma4QL0yL4WYFSz39GGZvgJgolpP8PFesmEfjlkTxii1I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765831592; c=relaxed/simple; bh=VCihespKqAvwz4ayGQuB9sxPczkPFI2wbSUtu79RQqM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LI2p5dnHcgQp/E68gjjPU422CAoVBXSYZhtB7Er6MFtUosl/Za3czcAKUtJhso+H7SdxGrVVo11wynMyteuRZ9qrepuxzv9wP+Q7Ycm1Py54YJpqInm4MHMkrcbmd8vw0DWsU3bgJJnbiFJiPhzV8MSP2BDPiivNKvl/X1ZlDLc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=mQKOms3G; arc=none smtp.client-ip=209.85.219.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="mQKOms3G" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-88a3d2f3299so12161176d6.2 for ; Mon, 15 Dec 2025 12:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1765831589; x=1766436389; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=c/5OmwgaCDghH9Y+B9p9dsz0t3uJjAxYmjjcZ3Iaws4=; b=mQKOms3GNbbYN9xNauU2u61awieNv24TitEmFkylCF397fggvINi0+sxqVUMnyyK4b r0DJ5Ls82S2GeuRtduBRiezdo1bi0zEgAZxtxFmcZLdVEs/jbfI0MF523t2FXmaIwRsU qSP/7c/hvS8L7TlbQxE6+bm/vKcfDQr6xQVyy6UOa3WtBfB8Sg/HGLqHz4wfUsIkBXL1 Ke+b9KoXcoZKTrvQTx9Ww/xvz6YpHgW2AomPKIyKS8qcZ9ZaFU8PuGcQtmV6oPvxwmID JV2kTZKqYtHjxPx8Z2VYRMpmnVyyauc/RHBWPaKZ+zdcPNq7wmLbf3zANEICTiDUUMyC cQSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765831589; x=1766436389; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c/5OmwgaCDghH9Y+B9p9dsz0t3uJjAxYmjjcZ3Iaws4=; b=w725K42Nmbp8Ut8qKArtnFOnc84r6bFHy5Cd5OJ80jcOT6Y0kyWgM3Mm4PuiPmEh2Z 6Fs/xV0XuP1luKj6OeapucxWq3ZVNVId5IcKk4snu6xo9+VjBYXwjYhPav0MLYCUAsH1 73gAzUuxNUBcMpufNxKvvMpoM4K8/YLkN0WSnWQtbTpWxiDGpbVNz6wrqbDjdbJooOyQ bo5fkhciYcd9KGm5TIDFPwXGKa/GMMisLMHLEyGxc5AhtQWLfTApDyWY4DzBL9X+ub2X fMXV+y9bT0sGpx6lUHlgH0Wgvy4pnLHT/UrOs59Fuz/Fd3l1G5HngPamp+SpzUeDZSFH ZyLQ== X-Forwarded-Encrypted: i=1; AJvYcCV7xseePqAJ8hS0gFDCoGCf9VWMUTVHejw7Z07mhDKjYiewrBceuaYbELdGqO1wBSJAXj0hSTNgCwwcF7A=@vger.kernel.org X-Gm-Message-State: AOJu0YxpXgD1D0G37qXbE7nzAcHPHmpcN0jmlUs6NpzcqkxTHWi4VHeC FMdkYEEWyPKgMMrup7WvYvhO2WtdYR3k/uWCJadXYLVBXy/PYWA3JDtgYSV2+8TMSe4= X-Gm-Gg: AY/fxX471w1XWyJgpZz+my8/wJ32uAjcTIozVC03NVmoY/cltsAd23GvJd9hAUJ5Jaj tkR0xwGV4c9lmxEfLi9UUTevJfI6pAmIVySGMaAe9G+xxECRE4NANa1lrq4RSJmDLFv05TDKli5 /R1fnNyqdK8bMx2kHv3Fgzj9iOMnYgL1MdV+HyCEV8RoWYPT6GLAYlfKsqQtgf85CxGREyJIRnE qSyKM4lpt0GYfMN9WvY9+GgAanAZIfsEY3ld0Mv/6EDsALylhlJUNNWYN10g5y1lKkcZeB7WQ2k 6koI8ZBXBdIrGkt23XKrVi/ebTEEsbLBHOlBeKFTCQh3Lcs1RRxSNSDRvNUGdATpxG1shJQcvv9 s3c8+9UivqS03xld6zjpwMoGJXe+aVjIeKus2rtjEzZr+qqmvWZKFfWbJRSjiPaouXj3mz6ov/N He0W6dQgavLg== X-Google-Smtp-Source: AGHT+IEECaGepI8b2WL9DLllMIh/MG6dmTXrWRWKDLKwFMYbp3fGB5X/Ym5XHJbEgAFZKvqnX0dTkA== X-Received: by 2002:a05:6214:4906:b0:88a:2f0f:c173 with SMTP id 6a1803df08f44-88a2f0fc33emr107185346d6.68.1765831588949; Mon, 15 Dec 2025 12:46:28 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88993b41dc9sm59677586d6.9.2025.12.15.12.46.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Dec 2025 12:46:28 -0800 (PST) Date: Mon, 15 Dec 2025 15:46:24 -0500 From: Johannes Weiner To: Dipendra Khadka 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 Subject: Re: [PATCH] mm/memcg: reorder retry checks for clarity in try_charge_memcg Message-ID: <20251215204624.GE905277@cmpxchg.org> References: <20251215145419.3097-1-kdipendra88@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251215145419.3097-1-kdipendra88@gmail.com> 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.