From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-117.mta1.migadu.com [95.215.58.117]) (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 580B7258EE9 for ; Thu, 20 Aug 2026 16:07:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.117 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787242045; cv=none; b=awNeiHrSa/LeyEippyrnxY2lc6UqTZIUG03FvEW+Z4C8j2asbQmeAchorDuZeqzCrDD/IS+6N1c+fNO/xqBJLKa6ZcjS11VEhGGfUUU62D01cE+V4akNFK+OKrDdPDUDjXbnY4jAG5k+fVMwSPukONUh8XQmdeDzLQVjUnzARqs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787242045; c=relaxed/simple; bh=53SX5U3+Y6dAV0m87LKeZ/fGFLwXadUJZBiDVWK3OgM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=J2AJzjx5OkN8uSvwr/96mdfx/lXKZ0wOWXp1JkTvvHUi/ZEhjIK6SNnIq9/Esj0A9fRBG4rF+7U3Y8NHBUKWirJCDZv32F5ypc2lLXDHmLaDh+tl0uYPTilR2GYq/N56yWWzJ4QpUCH2H6Us7dxhZ4mKbvyqU24rUVgF9V4krdI= 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=rMlvXdqP; arc=none smtp.client-ip=95.215.58.117 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="rMlvXdqP" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=53SX5U3+Y6dAV0m87LKeZ/fGFLwXadUJZBiDVWK3OgM=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787242040; v=1; x=1787846840; b=rMlvXdqP2XN0IXozCoszRUYPQx9p6/HFzPv3C5L4aduI/qjvHRAkBSF5rjnjIdmTMT/x0plt nnEW084aWJ/mmsDM9UbIR4sMV/pF1bVrTdbC9Tvu/GeY1FxvkhwA6FvnFfx1oXETWvTkn4DXEXX hJa/7e7lARUW/o4o67YYwgwU= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (2a03:2880:10ff:5::) by smtp.migadu.com with ESMTPS id e4605afa8f177308; Thu, 20 Aug 2026 16:06:30 +0000 X-Mizu-Trace-ID: e4605afa8f177308 X-Migadu-Flow: FLOW_OUT Date: Thu, 20 Aug 2026 09:06:29 -0700 From: Shakeel Butt To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , Roman Gushchin , Muchun Song , Joshua Hahn , Jakub Kicinski , Meta kernel team , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Joy Chaoyue Xiong Subject: Re: [PATCH v2] memcg: trim the per-cpu charge stock instead of draining it Message-ID: References: <20260820012010.2016086-1-shakeel.butt@linux.dev> 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: On Thu, Aug 20, 2026 at 09:06:18AM +0200, Michal Hocko wrote: > On Wed 19-08-26 18:20:10, Shakeel Butt wrote: > > Joy reported that an application generating a request/response traffic > > pattern spends 44.6% to 57.0% of CPU in the memcg charge/uncharge path > > for a range of message sizes, against 0.27% to 0.71% outside that range. > > Running from the root memcg, where socket memory accounting is skipped, > > recovers the performance. > > > > Tracing the charge path showed that the application generates a pattern > > where the write syscall charges one page and the read syscall uncharges > > two pages on the same CPU. This hits a corner case in the memcg percpu > > stock code that thrashes the stock continuously. > > > > In the memcg percpu stock code, MEMCG_CHARGE_BATCH (64) is both the high > > watermark and the emptying target, i.e. on a request to charge one page > > the kernel charges MEMCG_CHARGE_BATCH pages and caches > > (MEMCG_CHARGE_BATCH - 1) of them in the percpu stock. The following > > uncharge of 2 pages takes the cached count to (MEMCG_CHARGE_BATCH + 1), > > and refill_stock() then empties the cache completely. With such a > > pattern the percpu stock becomes completely ineffective. > > > > Instead of a single boundary point for charges, use the technique the > > page allocator uses for its own percpu caches, which keeps the watermark > > and the emptying target apart: nr_pcp_free() frees between batch and > > high - batch pages, leaving at least pcp->batch on the list. Add a high > > watermark MEMCG_STOCK_HIGH and, once the cached count goes over it, > > return only the pages above MEMCG_STOCK_LOW. The watermarks are > > MEMCG_CHARGE_BATCH apart, so a page_counter update still covers a full > > batch. > > > > For now, keep MEMCG_STOCK_HIGH same as MEMCG_CHARGE_BATCH and in > > future we will reevaluate if it makes sense to increase it. > > > > Reported-by: Joy Chaoyue Xiong > > Signed-off-by: Shakeel Butt > > Acked-by: Michal Hocko Thanks. > One minor nit > > > --- > > > > Changes since v1: > > http://lore.kernel.org/20260817234651.666540-1-shakeel.butt@linux.dev > > - Kept the upper limit of memcg stock same as before (Michal) > > > > mm/memcontrol.c | 25 +++++++++++++++++++------ > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 17da1f43b7d3..58e4d23cf5e0 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > [...] > > @@ -2254,9 +2264,12 @@ static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages) > > empty_slot = i; > > if (memcg == READ_ONCE(stock->cached[i])) { > > stock_pages = READ_ONCE(stock->nr_pages[i]) + nr_pages; > > + if (stock_pages > MEMCG_STOCK_HIGH) { > > + memcg_uncharge(memcg, > > + stock_pages - MEMCG_STOCK_LOW); > > + stock_pages = MEMCG_STOCK_LOW; > > I would find it easier to read to keep the update in sync with > memcg_uncharge, i.e. > stock_pages = WRITE_ONCE(stock_pages - MEMCG_STOCK_LOW) Sorry I am not sure I understand your suggestion. The WRITE_ONCE() is throwing me off. > > + } > > WRITE_ONCE(stock->nr_pages[i], stock_pages); > > - if (stock_pages > MEMCG_CHARGE_BATCH) > > - drain_stock(stock, i); > > success = true; > > break; > > } > > -- > > 2.53.0-Meta > > -- > Michal Hocko > SUSE Labs