From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (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 3DE3A322523 for ; Thu, 18 Dec 2025 07:36:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766043384; cv=none; b=NdASNMrebCCL1TlSYauEOqNUeKBFY1w77YBKE0ZX/Ke9dk8o04O7yQ9yi0q4ISHMJ0yBnSh++ZCHw2R66jvIbJmbuCvjmwuVBw6khQjDHAgQKmlOu8bb9Z6kkT9wt0YFDgEgYrqp3dy8d7ABI6KwVEyYZrHGZIx3uSuOG4xv4js= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766043384; c=relaxed/simple; bh=4aIek/r3ZvSZ4NS7Eu0mJEJ0FiVX1NZ7Td7KyjtnmOU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=s9d09T/A9Nm6iTI99zDhJlGnBRCGazDP1SkOpO7DGNNY+2bLt179hwR7DNjp+MkLPwREutgnChZif429D0ZtYRZzz8VqqQlV8Da7+ORl+3IBhWKbW6wxASn/lVpkz7stULfzNy1q1U7p7vMpZlb7wUGkghEpGu0KOeRVOrTNETU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=aei7zs24; arc=none smtp.client-ip=209.85.216.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aei7zs24" Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-34c3259da34so334735a91.2 for ; Wed, 17 Dec 2025 23:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766043382; x=1766648182; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=4aIek/r3ZvSZ4NS7Eu0mJEJ0FiVX1NZ7Td7KyjtnmOU=; b=aei7zs24OinNurGYasED2tRDPjSymQPV7V0B+zO5s2YqleQpDKTcdFNusKWp/fJnlV M89COSjo0WFJJ5tQ/yE189GVeO421tGPiyv0caT0Qkh5/IA+6r9BAd/IlRkzJTDyRl4m oUQe6tWHtsDuP6SkW+8Cen8IOivg2vVaAOhEWSsR8QA0BpOF9JqYk5MhPKNvPssBihkf fODEOdSxNmgatBR5dI8js3HVAQro2Ai6KMAYBvQizu36iz47DwdALgitWdJ/oM3cBVal o1RvpdX6qaXZUhNEYINen85s2vthypzLK2nIDQ6YDZPwX+RQ1FOwRqOrsisEgaBMBlwS 83Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766043382; x=1766648182; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4aIek/r3ZvSZ4NS7Eu0mJEJ0FiVX1NZ7Td7KyjtnmOU=; b=KOXDCl2nfnW03xwKC8EM56JryJr6QeGiYxpzkZdOEDt3uzlrcmVFbGstUJpSN6KLkd wIZlRxjvOw3UbZCBKBLXXfpHBkpS7IHHa2jiv6Ho4sxkJAbV+kYTeMvGtat4ilNmd/0W teqbHV8n9kF/hzSLL5m5iZEmxqXamQRqp8TP3hi3/uQhpoleFtbNE4lb2Hce7lSqLkws rpTCDXenndg4K5betF48nPIZwrYrEWHTlcCsmeTeekMxaJrDK7tw/6/yync+zxG4Sdv3 wkWfckfORioh4VCC96rmPJ21XUzUkjaKPI+NeBPEOOCNxY1XsRMkVHgUAoaMMr9Tj4sa r9tQ== X-Forwarded-Encrypted: i=1; AJvYcCVur1Fc+PW4jfBaRjMNAePH1/aflExDRoEfYdCsi4hpx2rmJk2yXeEkxd31QUI5oWwGwpzc2WuRgx3IXuE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzsfo5OZB30NhwuvFrVFObOMif++aA4DbemHsQh+kH0/+eLRj+5 Pc3jNJpmS8JFQB0Dxc9kmEIzIO410xrx73vZLTWDbRS6WMkkZhOTg+Sg X-Gm-Gg: AY/fxX7hjgn+j7xcjrHQFDCeDd3crNifoXDkQZAZju5z1lTSYFjXBzH9ID58yNHN4Ni XQISrQKIFeFlABv8FqLxPtQuC02P+yUeLjJsIwYUee51gcYhHnHM7GZPcc19pJlCig5mUB4QA4x MILFScqf0yTs4+UI1PdnrPjqRd58iRVoH85SXvgQoVWOKVG7AJvkQ3lWS/ZoVSWRFoHilAYGIu6 xAT4HdNAfGOSdM3uCoLnvCotrqXnrJ0OWgu6nLKGkhhTIbqUS330iayurNrRU/46CDQI8EAFeh3 E2N8+ZMzbTMONAYIAKidYWs5zzSQzO8emeDs3+ZZ/r7FiNEhY44c/+cnEov0GyFBMraIG4rLu1m SUv6wzUxJppwGPnIII9+MuSplUrv3pw5KdmLp/WQRePln4A2qpQ2m4UBJd6Rb694IgXLC9y3O/U SuWkhV2iIm X-Google-Smtp-Source: AGHT+IFvKKZA75dhAyRaTORAr0HnIA2q74dEctLS6i9INOz8BbZ7JdbmOc07paSWeFTnByMaRQX9GA== X-Received: by 2002:a17:90b:2b4d:b0:349:3fe8:170d with SMTP id 98e67ed59e1d1-34abe3dfe12mr16325954a91.3.1766043381960; Wed, 17 Dec 2025 23:36:21 -0800 (PST) Received: from ubuntu.. ([103.163.65.25]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-34e70c932casm1627169a91.0.2025.12.17.23.36.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Dec 2025 23:36:21 -0800 (PST) From: Dipendra Khadka To: shakeel.butt@linux.dev Cc: akpm@linux-foundation.org, cgroups@vger.kernel.org, hannes@cmpxchg.org, kdipendra88@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, muchun.song@linux.dev, roman.gushchin@linux.dev Subject: Re: [PATCH] mm/memcg: reorder retry checks for clarity in try_charge_memcg Date: Thu, 18 Dec 2025 07:36:13 +0000 Message-ID: <20251218073613.5145-1-kdipendra88@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: 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=UTF-8 Content-Transfer-Encoding: 8bit > Why hopeless? Because in this specific path the allocating task is already the OOM victim (TIF_MEMDIE set). Any reclaim attempt performed by that task is unlikely to make progress for its own allocation, since the kernel has already decided that freeing this task’s memory is the resolution mechanism. Reclaim may free some pages globally, but the victim itself will still be exiting shortly, making retries for its own allocation non-actionable. > Why optimize for this case? I agree this is a narrow case, but it is also a delicate one. The motivation is not performance in the general sense, but avoiding extra complexity and repeated reclaim attempts in a code path that is already operating under exceptional conditions. The early exit reduces retry churn for a task that is guaranteed to terminate, without affecting non-victim allocators. > Since oom_reaper will reap the memory of the killed process, do we > really care about if killed process is delayed a bit due to reclaim? Not strongly from a functional standpoint. The concern is more about control flow clarity and avoiding unnecessary reclaim loops while the task is already in a terminal state. I agree that this is not a correctness issue by itself, but rather an attempt to avoid redundant work in an already resolved situation. > How is this relevant here? This was meant to explain why exiting early does not introduce new failure modes for the victim task. Even if the victim still performs allocations briefly, the slowpath mechanisms already allow limited forward progress. I agree this does not directly justify the reordering by itself. > Same, how is this relevant to victim safety? Same answer here — these mechanisms ensure that the victim does not regress functionally if retries are skipped, but they are not intended as the primary justification for the change. The primary intent of the patch is to avoid retrying reclaim for the current task once it has been marked as dying, not to change OOM resolution behavior. If this rationale is insufficient, I’m happy to drop the patch or rework it with clearer justification or measurable evidence.