From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 DB3BC29B795 for ; Mon, 18 May 2026 14:57:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779116258; cv=none; b=HzuO7xehQK2KrjQK2IsG+AeUysLyKei8EjB3zOoa0Z8srqkSKT1ACGdCsCkFozgIFlj7tW0dXLjJcbX3WT+RS9wk8IqPIONkqXaj60JQvVodaNAT6UajqR2ylQycFrNA8rAx/cQ0cWlkPMqnSdQ3xolhEjqvjVEYtF9RNfx0aOM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779116258; c=relaxed/simple; bh=doEBG4FWrclg53f5OimQdkX3ilrMxQW1X1gRSd5DV78=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KCVGF+2yjdq5WAbSTwEQ5XKaL6qDy+esfsiJhcI05svvDxnXzjIZFFl8jOrNAIScmVCZhAi+xWLxFnNh3m3wyq9Iz093qkXv7ZgS0sv3jGVvSNzkEiUmcz5sd/uaZDptBJIJo9PRWoPe2owfXjvN+nUV6JM8MWY004bLfCvFIWY= 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=nU8Xsr5w; arc=none smtp.client-ip=209.85.210.51 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="nU8Xsr5w" Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-7dbd23bc684so1253576a34.2 for ; Mon, 18 May 2026 07:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779116256; x=1779721056; 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=jmbgY/AtPm2PbN1vZM05ZA7u4q3A7BXOzAlynye04/o=; b=nU8Xsr5wmviWpbDJPIuaUnQFsjSu8q3t1SWhpqVVCTHjUbdIA/4BXvCg2jQ1IN3Nae 7E/FvnnW8/J2pf9f23VBp7iaScKR1ZBUSzvbQHUcyQCzcOPLWn3jySo8Q4WMoPuLr0fC +i6DWe3wDSyrDyG+evVUa2enqYL4OSGOzfxfMHunMVVUYvRqnD7n0274753IR3Y4ul1W w70wcoL7YVwtjA9mlSllZ9BRbO0UZQAGs9kZGYEt5llh8v/QXhnyps8TzgqdKtar3zzd Fxpa8asej/R6gYjTeUq8WZA+hjIV5wqUDURMu+zbRmohSP8DmzI2L9osiySxL+Pz/eYg vPVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779116256; x=1779721056; 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=jmbgY/AtPm2PbN1vZM05ZA7u4q3A7BXOzAlynye04/o=; b=R/Rpm3x66ovlotKKylFlllXqPrYbZ12OwbalJ/kc/vkugHlGydHzefu2Dd5i+gU2bn fOiUGHq6xRO0ZQ694VWtDYVHIijVX+IDRfNJpNn5tea0VyvUNOtX8i9G7fnCUtQje059 tkGQNnuEir1uqD1mZUWySMKAupCeaRU8w35iO992cN3OqAsbqcmHpKgKbIK8Yro06gp6 KkElr5GCi8cwifImybKi4UNuJ/Kkb98ziIyOkLzmW4EVQ3COGOVcjApvmsbR7SohHCfE 4G5+dKrjuzvGiKTFwOpTh1v5BQattgRzCdQ9ZGsEw3X9Q4zlvnsk1LAHSX3aOLS/k1oL gpmw== X-Forwarded-Encrypted: i=1; AFNElJ/KQjVUb+vgLShcJNEkX56AQpW2FhFZ14Qs/qYbu7GtS0OPrYA0Rf/VDFp88R84dON4yQ0apx0kDruDm/E=@vger.kernel.org X-Gm-Message-State: AOJu0YwlddvhFTNLBKNmR4N/VEXpwzXM37Gnn6eAxN25n4bl7aehZ1ce itI1HR1h+ta1C8mSxl480kQiYczvRY4xmKxBQ3bB0kF7ZMMClitAcefY X-Gm-Gg: Acq92OEhtfGhxZIFy9VYBxYdBKni+sQounryqpb0jBlxnSVj1fkUea2cyi9EHUsxHdh W8rRKPYkBTwSzjrGO+2Ckyy9EZCYD7NEpZQFQd6WnKp9yYIXUK78Z5gpIOVD4sdWvTSsO7IOln0 zQjFWWiVS8h6Hw5SuirM5Nt81pkf0nKN8tR8epdY0eGM1yw+5kpGpvE4Y+mAsRrPJ0P5ATroShh CYIuerZ/VNxO08R72nlFXndGNZwtRhyU2EvtQBEoV2AJ+PgzMhHpuP86/hRxSnLcfUhjbknp2D+ iMYwT1ZzSlqSp7AxPAXDjTWmQMy/J7fp1N0E2WM5lggBNIbamMOc6gP9jUvAJkrcMc5FolgUHqE v1rtMhi2ACPfCujgi4QwmhqDQuVf4xwTaItTJoX8+kDSYF2TNf0diSzCCNlTChZIsqWh6cEAV70 IBIiHb9ZKbDfAnby+gXcHyBFOj0eDaJmzZRJ5VzmbSoj0vum6+FXXl1Q== X-Received: by 2002:a9d:454c:0:b0:7e5:b3f6:c6ad with SMTP id 46e09a7af769-7e5b3f6dde6mr59032a34.4.1779116255749; Mon, 18 May 2026 07:57:35 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:47::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e55bbd10aesm7741729a34.18.2026.05.18.07.57.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 07:57:35 -0700 (PDT) From: Joshua Hahn To: Alexandre Ghiti Cc: Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Dennis Zhou , Tejun Heo , Christoph Lameter , Vlastimil Babka , Yosry Ahmed , Nhat Pham , Sergey Senozhatsky , Chengming Zhou , Suren Baghdasaryan , Qi Zheng , David Hildenbrand , Lorenzo Stoakes , Minchan Kim , Mike Rapoport , Axel Rasmussen , Barry Song , Kairui Song , Wei Xu , Yuanchu Xie , "Liam R . Howlett" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH 0/8] per-memcg-per-node kmem accounting Date: Mon, 18 May 2026 07:57:32 -0700 Message-ID: <20260518145732.349196-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260511202136.330358-1-alex@ghiti.fr> 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, 11 May 2026 22:20:35 +0200 Alexandre Ghiti wrote: > This series pursues the work initiated by Joshua [1]. We need kernel > memory to be accounted on a per-node basis in order to be able to > know the memcg and physical memory association. > > This series takes advantage of the recent introduction of per-node > obj_cgroup [2] and makes those obj_cgroup tied to their numa node. > > The bulk of the series is percpu per-node accounting: percpu > "precharges" the memcg before we know the actual location of the pages > it uses, so charging and accounting had to be split. All other kmem > users (slab, zswap, __memcg_kmem_charge_page) are straightforward > conversions (zswap support is limited in this series because Joshua > is working on it in parallel [3]). > > Thanks Joshua for your early feedbacks! Hello Alex, Thank you for your work! Overall I think the direction makes sense to me. Pre-overcharging makes sense to me as an approach, we would much rather overaccount than underaccount and later have to breach limits. I do have some concerns on performance, though. Namely, I think there are some expensive operations that I think would benefit from some performane benchmarking with this patch added (maybe some simple microbenchmarks that demonstrates kernel allocation overhead could be useful). >From what I can tell, there is some additional performance overhead that has to do with iterating over num_possible_cpus() x pages_per_alloc, which doesn't seem trivial to me. Another concern that I see is the stock credit system. Maybe we could be bypassing the stock check leading to more time spent doing the atomic operations. obj_stock caches a single obj_cgroup, which means that if we split the objcg to be per-node (in patch 6), then the obj_stock basically gets invalidated every operation since we iterate over more objcgs (even though we are in the same logical objcg). Maybe I'm missing something? I haven't taken a deep look at the implementation details but just wanted to raise some high level items that I noticed. Of course, all of these concerns are just theoretical, if you can show that the performance delta is not noticable then all of my concerns don't matter. I also want to talk more about the local credit system but let's first see what the numbers are first. Thanks again, Alex. And I really like patch 2 because it is a solution to a problem that I ran into in my percpu tracking series that I couldn't think of before! Thank you for solving my problem too : -) Have a great day! Joshua > [1] https://lore.kernel.org/linux-mm/20260404033844.1892595-1-joshua.hahnjy@gmail.com/ > [2] https://lore.kernel.org/linux-mm/56c04b1c5d54f75ccdc12896df6c1ca35403ecc3.1772711148.git.zhengqi.arch@bytedance.com/ > [3] https://lore.kernel.org/linux-mm/20260311195153.4013476-1-joshua.hahnjy@gmail.com/ > > Alexandre Ghiti (8): > mm: memcontrol: propagate NMI slab stats to memcg vmstats > mm: percpu: charge obj_exts allocation with __GFP_ACCOUNT > mm: percpu: Split memcg charging and kmem accounting > mm: memcontrol: track MEMCG_KMEM per NUMA node > mm: memcontrol: per-node kmem accounting for page charges > mm: slab: per-node kmem accounting for slab > mm: percpu: per-node kmem accounting using local credit > mm: zswap: per-node kmem accounting for zswap/zsmalloc > > include/linux/memcontrol.h | 27 +++++-- > include/linux/mmzone.h | 1 + > include/linux/zsmalloc.h | 2 + > mm/memcontrol.c | 150 ++++++++++++++++++++++++++++--------- > mm/percpu-internal.h | 16 +--- > mm/percpu.c | 90 ++++++++++++++++++++-- > mm/vmstat.c | 1 + > mm/zsmalloc.c | 11 +++ > mm/zswap.c | 9 ++- > 9 files changed, 242 insertions(+), 65 deletions(-) > > -- > 2.54.0 > >