From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) (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 EEFFA2EACF2 for ; Mon, 30 Mar 2026 21:18:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774905492; cv=none; b=NsAh5yFxMjFElYhtrUXK6dkK6sLDwcvSrdBjdmGdlt4QgSjZUDLnac1GfpKnSx/LoF/g+XVkbQpxTYaWjdM0LA8mwSiW3ZoRe8CVbBUO//KAV1AJiS6DsTOlsMgtFHro1WD1bhlbRUy5UF3jMn4q5yWYyQx1YEYRXWDIfftCzmA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774905492; c=relaxed/simple; bh=gST/9RRrMQTtXqyOvwpjZs+8sip20ZbFBGJzGchU/jg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tLHJlHLsfsWNKFTlDMP9BI0Pkm7a033Jw9dZHELOQB/IYhyw5gQuuU06aafwXejz3iSU9mwICGgkdNFB6BtRZIiAROQJpOio8XMlRLNfY8VM+w8Jh6xsw1SHDMPiudUXH+ghoypLGpJoQdcPjms9Km1mkgXqh2xErI2T5gTMExg= 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=tDkSvbLf; arc=none smtp.client-ip=209.85.160.50 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="tDkSvbLf" Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-4042905015cso3024634fac.0 for ; Mon, 30 Mar 2026 14:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774905490; x=1775510290; 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=YpynBP+G3ZnDHhHUsVCEALCguQRacTThLF+4zfYVNbU=; b=tDkSvbLfF5r/zlVNRlxJFgk+bYMyvRYlhgTVJC+jUlh8tpX6p0HOsbbTJq4LJhOwxg JgoVKfOhi0JZGKZ9HXN9bTl8IN8/yG1j1tnZS9IpyucGsCcOej9cTJrCtJUCADRxo9D0 ykeCQhFdXQiFTFv9VyZuiq3n6WvqUTZUcbczuh5rWYf41cwAPdmQtpESIDq9Q2LggxiT /+NxNM05q3qAS59aDXyRtbxr3Oa6tckAYXDmmQkQ9iy41jWEnGNhIhrjpLUq42nOTZMY g6xGaXDJuPoreP/jbTKv+EVLJxhxaZ+9JJTHkLYvsr3nTHHQabVsJ77OEr1ZIJL77HQq ATTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774905490; x=1775510290; 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=YpynBP+G3ZnDHhHUsVCEALCguQRacTThLF+4zfYVNbU=; b=Xpt7zAjDsLzIrlX6BA3BFshhtdscBgKw1fxWsZCt0TN/FxU/tQQJBLktI6KPrHP2bG n1z6baGZ8cHsY9PQjuNiLd8Ldcad/h0LEm7b0o+G/m5oepDcz+0QFP5iVGbAn1hiL5Xw qsaz7IIV9eTgaPD07WdWAjCT4Wjz0ZXtMLHuMiD7Pm8J3t5juDzyIv8zmv+G1LOMSanF YwE7UihNvtmYbzP1NS3YD6XEn4EwWtgbmlSKz/8760sG+INtvepfLLS0+mHVzXpKTcvm N79U3rA3OTHdzteCEZXppQ4dBAklCvRiA+bgcIaKj+vx9F2Xjddot9mkziIfBnX693PR xuGg== X-Forwarded-Encrypted: i=1; AJvYcCXerv3xrwfJ65OGqaG8AEBdv1TcvkndE0NuGi6JGe405fcRUCf9+cpZPiclIvhbgqCgBPoJKf+rYsv21r8=@vger.kernel.org X-Gm-Message-State: AOJu0YzxUQJoPr5IMkd8sauaLoI19lhoHqjVuZOy8rneM8p9EXPJJ8hB kXJBpToj31cDELBSsRoh0kE9iF2SgH2zVBn6D5AeyrPAbeo1P2kxAy+QDp2aUw== X-Gm-Gg: ATEYQzwDSn9KZ/kwurYbHTPC8H8obrvLhilFXBmEWuHlnJpDrDlTz+7YsSUvybSY1+V M1tw96LqQ7jJE6tunsTczqLpa7XjYt5QQXq6414stezlIlN44ig576c5JJhrrQcdIX/cYWGa5YL KSmXw7FdcUEwh83IxUXeFPLfEc1Ere3/y3Fbiw7nF/mqkB3zT4+1atVzdgL2pUHTkCP6+NYtITe 7v9vQ2BrpvB5m0dOPw+t59LT4bQW47Ek3kV4shgPSI1r/RWvLZw+v4JIY9UFkaoH7OK0PokgRhn b51v+pxk/nMkHrmBbxYBWwnKNIgxKPeackUcm1Uw6u89NPjC02XD+pqF5jYk9FlWcgTcRGVIvpH MWjeX/X8pF5S7Im1oh2YeasYvxUDb2Wg7//300mUWB9gZofM18oQKcVho1C5GaHZshMq2rlQ5o2 hQHMQHslwLmCxrwaIz5+CGNw== X-Received: by 2002:a05:6870:b30f:b0:41c:6512:8419 with SMTP id 586e51a60fabf-41cec27e409mr7957130fac.28.1774905489749; Mon, 30 Mar 2026 14:18:09 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:5f::]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-41d048e1984sm5978777fac.4.2026.03.30.14.18.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 14:18:09 -0700 (PDT) From: Joshua Hahn To: Michal Hocko Cc: Johannes Weiner , Andrew Morton , Roman Gushchin , Shakeel Butt , Muchun Song , David Hildenbrand , Lorenzo Stoakes , Vlastimil Babka , Dennis Zhou , Tejun Heo , Christoph Lameter , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH] mm/percpu, memcontrol: Per-memcg-lruvec percpu accounting Date: Mon, 30 Mar 2026 14:18:07 -0700 Message-ID: <20260330211807.349539-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.52.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-Transfer-Encoding: 8bit On Mon, 30 Mar 2026 16:21:12 +0200 Michal Hocko wrote: > On Mon 30-03-26 07:10:10, Joshua Hahn wrote: > > On Mon, 30 Mar 2026 14:03:29 +0200 Michal Hocko wrote: > > > > > On Fri 27-03-26 12:19:35, Joshua Hahn wrote: > > > > Convert MEMCG_PERCPU_B from a memcg_stat_item to a memcg_node_stat_item > > > > to give visibility into per-node breakdowns for percpu allocations and > > > > turn it into NR_PERCPU_B. > > > > > > Why do we need/want this? > > > > Hello Michal, > > > > Thank you for reviewing my patch! I hope you are doing well. > > > > You're right, I could have done a better job of motivating the patch. > > My intent with this patch is to give some more visibility into where > > memory is physically, once you know which memcg it is in. > > Please keep in mind that WHY is very often much more important than HOW > in the patch so you should always start with the intention and > justification. > > > Percpu memory could probably be seen as "trivial" when it comes to figuring > > out what node it is on, but I'm hoping to make similar transitions to the > > rest of enum memcg_stat_item as well (you can see my work for the zswap > > stats in [1]). > > > > When all of the memory is moved from being tracked per-memcg to per-lruvec, > > then the final vision would be able to attribute node placement within > > each memcg, which can help with diagnosing things like asymmetric node > > pressure within a memcg, which is currently only partially accurate. > > > > Getting per-node breakdowns of percpu memory orthogonal to memcgs also > > seems like a win to me. While unlikely, I think that we can benefit from > > some amount of visibility into whether percpu allocations are happening > > equally across all CPUs. > > > > What do you think? Thank you again, I hope you have a great day! > > I think that you should have started with this intended outcome first > rather than slicing it in pieces. Why do we want to shift to per-node > stats for other/all counters? What is the cost associated comparing to the > existing accounting (if any)? I went and ran a few tests, which seem to show rather negligible performance differences (phew). I wrote a kernel module that does 100k percpu allocations via __alloc_percpu_gfp with GFP_KERNEL | __GFP_ACCOUNT in a cgroup. I then measured how long each allocation takes across two trials, one where I do all 100k allocations and then free all of them at once, and another where I interleave the allocs and frees. Everything below is ns / alloc, and the +/- is the standard deviation across 20 trials. +-------------+----------------+--------------+--------------+ | Test | linus-upstream | patch | diff | +-------------+----------------+--------------+--------------+ | Batched | 6586 +/- 51 | 6595 +/- 35 | +9 (0.13%) | | Interleaved | 1053 +/- 126 | 1085 +/- 113 | +32 (+0.85%) | +-------------+----------------+--------------+--------------+ I'll include this, as well as the additional memory overhead that Yosry suggested to include in a v2. I think we can get more accurate accounting by distributing the obj_cgroup pointer size across the CPUs, so I've gone ahead and made another iteration. Thank you again for your insight, Michal! Joshua