From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-35.mta1.migadu.com [95.215.58.35]) (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 275B944BCBE for ; Mon, 31 Aug 2026 17:52:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.35 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788198769; cv=none; b=WtDb4bIw+ewf2krLNQpJDsqICO1nbURGTF8zaDWApjV8zpDXwLmrzq0B5K3sbrAaqlMzIy3H+2/5JEl0/tIl/X1cnWEpis2F9GCWdD2OtBh8umjxbo218YG9/NOBBja/6v9PC0xV6ug5pIhQQBTGAYsPJdpoVofIAXXKs/5A8bE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788198769; c=relaxed/simple; bh=BsIgtLWDoXUh0LcK2P6/hUTeOlcXonOAihqw77WsqZc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Nxyccjzb2lytYG8rdqp9RSawKgAW/rm1F0jb3bUDxSECAvpSIyq2+jIUdju3tomrpYMNo8da75d6PuNShgAqsqYTMEWKpxQgrpIs11xQ18YGGvCltvXr2RG6p192HcGUqeCPEnqTtbwIXYfDHtxYShamSIWEAFY5d9a1/dH2Nlk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=r0PtDBGA; arc=none smtp.client-ip=95.215.58.35 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="r0PtDBGA" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=BsIgtLWDoXUh0LcK2P6/hUTeOlcXonOAihqw77WsqZc=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788198765; v=1; x=1788803565; b=r0PtDBGAj5IPiBeH2SDudqKC2RXht5AJf1i3TPIM/ShKr5UjrEIGzrrxlSrd7WLEKYlzWB16 8ZFqnJNkT8PXguO8dx98psj1ayqOCFBGVAA2noX3QcTfBj44bjJjTPBWRHbWtRupMXyjD9gc1fW rsl4nnMe6fS1JxEiL9wo2eOk= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id d7054335f12e2924; Mon, 31 Aug 2026 17:52:35 +0000 X-Mizu-Trace-ID: d7054335f12e2924 X-Migadu-Flow: FLOW_OUT Date: Mon, 31 Aug 2026 10:52:32 -0700 From: Shakeel Butt To: Joe Damato Cc: linux-kernel@vger.kernel.org, Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , stable@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org Subject: Re: [PATCH v2] mm: memcontrol: raise MEMCG_MAX for charges that fail without reclaiming Message-ID: References: <20260831174836.3102406-1-joe@dama.to> 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: <20260831174836.3102406-1-joe@dama.to> On Mon, Aug 31, 2026 at 10:48:35AM -0700, Joe Damato wrote: > Charges that exceed memory.max and return through the nomem label can > raise no event and simply return -ENOMEM. > > A non-blocking charge can hit the limit, get rejected, but is not > visible in memory.events. > > This was noticed in a production setting where bpf_mem_alloc() attempted > to refill its per-cpu freelists, which triggered a non-blocking charge > while at the limit. > > Commit d6e103a757fa ("mm: memcontrol: do not miss MEMCG_MAX events for > enforced allocations") added raised_max_event to cover charges that are > force charged without ever reaching reclaim, but charges that are > rejected outright were left out. Getting an allocation failure without > the corresponding MEMCG_MAX event is unexpected and makes debugging and > monitoring harder. > > Raise the event on the way out for rejected charges as well, by routing > the -ENOMEM return through the same exit path that already covers forced > charges. The existing behavior of raising a MEMCG_MAX event on every > charge/reclaim/retry iteration is left unchanged. > > Tested with a module that performs accounted GFP_NOWAIT page allocations > from a task in a cgroup at its memory.max, and measures the resulting > memory.events:max delta. Without this patch the rejected charges raise > no event at all; with it the delta matches the number of rejected charges > exactly. A GFP_KERNEL|__GFP_NORETRY control, which reaches reclaim, raises > the same two events per failed charge before and after, confirming the > existing charge/reclaim/retry accounting is unchanged. > > Fixes: d6e103a757fa ("mm: memcontrol: do not miss MEMCG_MAX events for enforced allocations") > Cc: stable@vger.kernel.org > Suggested-by: Shakeel Butt > Signed-off-by: Joe Damato Acked-by: Shakeel Butt