From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.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 E42F93ACA72 for ; Mon, 30 Mar 2026 14:10:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774879815; cv=none; b=YtggCiZPK+I3YXZqREJVkQCzf6Jc8h4ovx5ap2aXVtBz9Eg/LV5oka3CN16BtskwlQl+rRDayWwViVTaUJ+EOthfdPda8CmYuOdLwWbvthvCsN5QlnRTmQ/I6x59KKZ8BBx9dLnqTTPB3DJWthVQOGgyFap5Z+BRPKo5jobgf3g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774879815; c=relaxed/simple; bh=X00iyPLUf/MpgfrLqE3IToB+I0uP/6U1vsaQL+fdMys=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tFrXfHeM50x1oNwVuj8SA2rk2ylyIe1kroiEs9GRvEqalpucJvL0MHx5yL1mV8HIe6YEUOzs9H+SjA+ToVkDasEBchNv8Vi+aTwdSoxAImcELcM/pe7Q9z9TmJY7DhEnu9BUAHIYP328hBxHDii+qLakdvoEX40qa74Jzft8XcQ= 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=oZupGTnj; arc=none smtp.client-ip=209.85.160.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="oZupGTnj" Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-41c4d660b19so1377396fac.1 for ; Mon, 30 Mar 2026 07:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774879813; x=1775484613; 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=/xL8uHHzuWMbBwJ5+3HtVtL72FNsO/9cgkReiuuiZMA=; b=oZupGTnj4fgdCSUDtq1ZZfq2TTfJxcVfwZjAI+/YjzKVQiE+T6Fta4vVNVEY4ExofD 7M+vkwxyUjHHpUYAP0Ex2cZ3OCaSf8OLIv9eH4y4IM8aYdka5KrDb4OWt38qJqSRkAQ0 QvzJLg6XZnVXQB3V9pKkv1yfvv6Zt60ugVTJE0nsCQNf4FVUXsUxsF7u8sHUGHZDOqP9 S4MVO/eJphA+PwluE8Ay+5+sJZUV9HEseQCmzEoRtFgWxbNjUTkyH1+8FK+kBVxCevIw wlxLLKc8bFp2UNL4TZ+hmtv9D0/GTobE7P7k9ltXq9WJPTdkX56ZX2KCvDSRv0uto4JX mAOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774879813; x=1775484613; 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=/xL8uHHzuWMbBwJ5+3HtVtL72FNsO/9cgkReiuuiZMA=; b=s+xzca2oVxG8rCRLvnaHZkWBbC36LBJ4cfaxDP2mJwQT6JzY+7vF+pKGf3RPyEyNfU gvHh9fpA0rvUMzK9wMtMZ1gW+6AdpYkgZF6+4XiGBAMKNQnOvlI1hE31Zp86mSJ3G/3p X0Kz9b70jEB6gRc1mr44lMRTR8Ubmo8DPuMMorfdG89NfVMOxyDAr3eCVYs0vOzcqwFF wjTqknnJniMAgwxzrsF11DeXvZQYYVuz3NL2RlaAq9qukas/Os3jMpQB5ouL29aQtW+Q UpIylW20TZoqoLPQOZ3ml5f6x/54CSMPGnKd/rztDMpkAd/K4wlnGSi6LjmE+KVvp3sx g4rw== X-Forwarded-Encrypted: i=1; AJvYcCViGV3O12AN6m2PClw9rVHiuPfyAs4jj1WjQgog5Ya8ERLpmH0ZKlMVBKC45c2Hu43LK9ZX4IBwmrNirc4=@vger.kernel.org X-Gm-Message-State: AOJu0YyCqnfcsgJIBj/i0tCErIRuCgyJPTQgypVoaHMuKTrev/3V5Hms /bIpH0kB5XnyXr1aVV/UMRhhbsMaRB64N9MCxi0GwtKlodCzVMQr7J10 X-Gm-Gg: ATEYQzwE/VzJmTorDLbH8IXc3waFBqAZA+HrCQ9e6AKOVppKV47LrPOT1ujPGyqZzFe GbsNb7jUYttGf7pTjcAqOxOVTaJKS1XNKn7Pxh4TXWTZjg2xYdo1Q42UaAId4Uh6j81QKCxBDQ1 knp2/EEoBL+X2Fpo6PBGnWTl40mvEGup2vls3eL06PW+c9C2RxtqFqdOfyu+KEB8mM7q/9biN3t rR1hdICjVYTYoDNfsTurMaOREf6ipfvHpqQXgK1Ykwu/nhskPIQoMTwdhqUYniRaAZZCuI5Jxrs UCCeZtdmIRUyeTt8ooh/iA3RxKT7EIngufPeEzg7luH0rksb3/Cqz84pTo/YKwSoTT3fpw3RhmB 9pxKOaxWxTQYvurbX4Z/qJLgKA/5qVYccnCIDxBLXoBBgFhX5z7edC5YBvEG5RIVLcsO9cSmP80 Qku5MH50F3ZNFc//3/FLTK X-Received: by 2002:a05:6870:612c:b0:41b:e9c4:9778 with SMTP id 586e51a60fabf-41cec29a8eemr6470923fac.32.1774879812679; Mon, 30 Mar 2026 07:10:12 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:7::]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-41d048e1961sm5508071fac.2.2026.03.30.07.10.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 07:10:12 -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 07:10:10 -0700 Message-ID: <20260330141010.3126996-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 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. 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! Joshua [1] https://lore.kernel.org/all/20260311195153.4013476-1-joshua.hahnjy@gmail.com/