From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) (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 D1A3D1E520A for ; Tue, 24 Feb 2026 00:19:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771892357; cv=none; b=eaBE1666ygaKgXDUh30KihAX6APVTsp5PNfWr6ycfJ7wbFijyzjnDbRnqIRLgzZhjG0HT2oEHIqnNx20FsPZn3ypsm3iWCTUb45YZANHtt+WBgbEwu7/oOpnXoz47eCD5hJ/mdFyIOEw67LuCRkCl+dU4zcx3udnjNRp3puVn0w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771892357; c=relaxed/simple; bh=E8aK7KidsxhYI9fT3xeIpRXL2fMl/FJi1hO1vuu1bMY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=GE+Mopn76Q0pF0nHlkjgwfRt5yGq/EPd1Oz6+FQsLI4P5XMUWpTTSOgA+1PgYm0DCHh2ArfesJ55lelwjMI+ohpnznfxvbg7R0TtkK2k6aXh9HYimmYBRiO8VPWe9E3jpmcdI4zh6EzCpyE9Zof5giz3nfPCBEUR2z3UBxdATY0= 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=gkNMxEvr; arc=none smtp.client-ip=209.85.221.169 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="gkNMxEvr" Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-56637565faaso4059129e0c.1 for ; Mon, 23 Feb 2026 16:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771892355; x=1772497155; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=r71zDlsdwqZwuXP6L6SMlSArsf0mkKQK+1/SxbuvMeM=; b=gkNMxEvrjN/Vpsp7qkgvX9tHnAtf8UHPNhfHIVB76BzMmf9ZSqVc/Xrrdqrp59HzdT vosSLwHUZJRAExwSuEvyp9PmVrjhUkY3sf4y68i51KxFKkdm5k4BP/ETP+tq2nLvHJXx MoCsfKrnKik8HQIvCZ1U2Cf+t5VavSHTr+5H6zih/BpRr/jSIvH0wbRX7oinZR2aR7zn mDcxaIJasLKjj8lhYAowCdkrK/sLcKd9XMO2J/P1ELuKv6K+ZA5F+7AS+P0h4cAZWGM3 w49EsdbM7oUZQUqy7KC88jk33gKzSErXSeFISOFIvjsGFx5kFx+Jy2WvmpdLo4jo+QsV 3eoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771892355; x=1772497155; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=r71zDlsdwqZwuXP6L6SMlSArsf0mkKQK+1/SxbuvMeM=; b=pPKS1ck1NKAzoYn4+IfccIyiTzOqbwg4qksGx16PiyM7SJbeSCc7NHfrDS6NsT4D0B JwOa5gM6F7gzwfTQvhL4YD+UcX8bpc05B/4+WcjZoPtGSpIeP02B5lUEDMFD5UyzegmA nxAdfoMXc1DL3knyruXtKRI3lgNyiM/rt4uJhkiT5bwSOW2t7sC/8FpQWouxlNzSamO8 RofibVt3MHCYQ/2/4+n+spnZG0N9wuCYFbivQv1Mqy1GcGXS7Pg1sh28qqIXOOWioQvm 9ms8UVHPKIsHK5aO+smy3aULPdM207YesD0rDCtgjphGfUePGfzBbSlYjEFLFa8IrrGr 3fyg== X-Forwarded-Encrypted: i=1; AJvYcCUf6chjB31G9pZf+HBPdqHB/tCzm4PhperXF94BzptG8tfB/fFS4ADQbMXtvkpqx3hRv5xS3rItREgd2P4=@vger.kernel.org X-Gm-Message-State: AOJu0YwwNqIxJO0lMtr2mES0LB0g4HWJ3ZRqrpmX8Ld2irSNNTvVhOjp /a62X71eT9D2cAHrWTWxfAFMbKnoOf0wx4SwGMVBQS5Wt98G3GGLqhNWvucp2g== X-Gm-Gg: ATEYQzzCrYXA6whtUDKy8mG4tz7qonhudAq372fcwd1k02lSJ9xd+bdriXRFkEA2tU1 /KZKJJCmEZ5X/KxK4/UMHblbUkTR9ivIM60TcbNTs2AU0k1iXgafwabrjjwPoZjhbThTzxmjR1/ KUc0Mv0tQh9NQMpBHuKrOC4/CCxxQTtjfeIRdmhYtZzYZB/KiQ4b/FKNeOjX0AJcQ+KszkJ6dr6 clGozw9MRkAGNPWN0GP2ReywiE8DFhg4Hf6PnoJg4th5dNKZx0/TMp2L+EX82glBul8ObENYf/9 nKjaApUymB/NsO6gRVqytc1N6QMiZBR96RIZoFS4FU9KrhqyYG6rymCv3zGyz0h8brsSzT6ONho AkrS0zlROTd+CCnqHGVrdci/unGnYYrdswvXeRJ31ZTmUgbt4noG3fSkPQJeiR1+n9XTSMP0zVd Wj+yd2ABQ4KLGSYO53XyvvfYfIUeQPeHEL X-Received: by 2002:a05:6820:2d0b:b0:679:92c7:2c07 with SMTP id 006d021491bc7-679c42784famr5858006eaf.29.1771886313849; Mon, 23 Feb 2026 14:38:33 -0800 (PST) Received: from localhost ([2a03:2880:10ff:53::]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-679c5630a4bsm7167922eaf.2.2026.02.23.14.38.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 14:38:31 -0800 (PST) From: Joshua Hahn To: Cc: Gregory Price , Johannes Weiner , Kaiyang Zhao , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Waiman Long , Chen Ridong , Tejun Heo , Michal Koutny , Axel Rasmussen , Yuanchu Xie , Wei Xu , Qi Zheng , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: [RFC PATCH 0/6] mm/memcontrol: Make memcg limits tier-aware Date: Mon, 23 Feb 2026 14:38:23 -0800 Message-ID: <20260223223830.586018-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Memory cgroups provide an interface that allow multiple workloads on a host to co-exist, and establish both weak and strong memory isolation guarantees. For large servers and small embedded systems alike, memcgs provide an effective way to provide a baseline quality of service for protected workloads. This works, because for the most part, all memory is equal (except for zram / zswap). Restricting a cgroup's memory footprint restricts how much it can hurt other workloads competing for memory. Likewise, setting memory.low or memory.min limits can provide weak and strong guarantees to the performance of a cgroup. However, on systems with tiered memory (e.g. CXL / compressed memory), the quality of service guarantees that memcg limits enforced become less effective, as memcg has no awareness of the physical location of its charged memory. In other words, a workload that is well-behaved within its memcg limits may still be hurting the performance of other well-behaving workloads on the system by hogging more than its "fair share" of toptier memory. Introduce tier-aware memcg limits, which scale memory.low/high to reflect the ratio of toptier:total memory the cgroup has access. Take the following scenario as an example: On a host with 3:1 toptier:lowtier, say 150G toptier, and 50Glowtier, setting a cgroup's limits to: memory.min: 15G memory.low: 20G memory.high: 40G memory.max: 50G Will be enforced at the toptier as: memory.min: 15G memory.toptier_low: 15G (20 * 150/200) memory.toptier_high: 30G (40 * 150/200) memory.max: 50G Let's say that there are 4 such cgroups on the host. Previously, it would be possible for 3 hosts to completely take over all of DRAM, while one cgroup could only access the lowtier memory. In the perspective of a tier-agnostic memcg limit enforcement, the three cgroups are all well-behaved, consuming within their memory limits. This is not to say that the scenario above is incorrect. In fact, for letting the hottest cgroups run in DRAM while pushing out colder cgroups to lowtier memory lets the system perform the most aggregate work total. But for other scenarios, the target might not be maximizing aggregate work, but maximizing the minimum performance guarantee for each individual workload (think hosts shared across different users, such as VM hosting services). To reflect these two scenarios, introduce a sysctl tier_aware_memcg, which allows the host to toggle between enforcing and overlooking toptier memcg limit breaches. This work is inspired & based off of Kaiyang Zhao's work from 2024 [1], where he referred to this concept as "memory tiering fairness". The biggest difference in the implementations lie in how toptier memory is tracked; in his implementation, an lruvec stat aggregation is done on each usage check, while in this implementation, a new cacheline is introduced in page_coutner to keep track of toptier usage (Kaiyang also introduces a new cachline in page_counter, but only uses it to cache capacity and thresholds). This implementation also extends the memory limit enforcement to memory.high as well. [1] https://lore.kernel.org/linux-mm/20240920221202.1734227-1-kaiyang2@cs.cmu.edu/ --- Joshua Hahn (6): mm/memory-tiers: Introduce tier-aware memcg limit sysfs mm/page_counter: Introduce tiered memory awareness to page_counter mm/memory-tiers, memcontrol: Introduce toptier capacity updates mm/memcontrol: Charge and uncharge from toptier mm/memcontrol, page_counter: Make memory.low tier-aware mm/memcontrol: Make memory.high tier-aware include/linux/memcontrol.h | 21 ++++- include/linux/memory-tiers.h | 30 +++++++ include/linux/page_counter.h | 31 ++++++- include/linux/swap.h | 3 +- kernel/cgroup/cpuset.c | 2 +- kernel/cgroup/dmem.c | 2 +- mm/memcontrol-v1.c | 6 +- mm/memcontrol.c | 155 +++++++++++++++++++++++++++++++---- mm/memory-tiers.c | 63 ++++++++++++++ mm/page_counter.c | 77 ++++++++++++++++- mm/vmscan.c | 24 ++++-- 11 files changed, 376 insertions(+), 38 deletions(-) -- 2.47.3