From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) (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 6C0AC37AA7F for ; Mon, 22 Jun 2026 22:10:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782166241; cv=none; b=O+pT+Pv31+M27AI14UiWrrxeIN1jzTOPyRJh8N1ku09xWmD1x5y7eVTNCEBl7GGbQfXToOewl2RfyFj1bY0PB5qxQ08WTR0kXdbWei4HEQbLo03USYJHpOM+U7+DpUxBuXpT81frLXHRmcTIzZqbs9DOwKDmQ9wShj/Bzs9cwTg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782166241; c=relaxed/simple; bh=PX27CGIChTktajqQRqdehsvfssAJs/ydFa86KHvUuzU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OK/tnRzky+fz/ZKTpdol2bS32TpNLVbEFCSy+WuBe4Mynfy274zDOxd/1ALpIhk8JepMTMKm72u2oUKpLHSGy7hkQeWjbbQnLErMbNA7xYXAtha1a4r4Jwn3JjOlI61J44FJ7YNHkXgXtVqZ676UTBBV0Ek5+VbyPqlvnprN3l8= 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=L42WL6BK; arc=none smtp.client-ip=209.85.161.41 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="L42WL6BK" Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-6a0ddedcd00so1483024eaf.1 for ; Mon, 22 Jun 2026 15:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782166239; x=1782771039; 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=/lWcRJ9xv3vj+kuUslXqTMu2ZS1PDN9hlN/ZqmuvJzU=; b=L42WL6BKh/4Ouo6mVBE+q0FXy32aKOMBm2W9GqLrNtjrUgJgD7fOSbQd1W4VBBGbiS HOfNPGt83JHLSau6DbQRQ72uq2vfSxzeEzJOetnXKNbNNKwl44rVgRuIRQq3uIdru3vE BW3ywQy0nq7hn8mdiVmT9oxH6q31n1eEo5BzE1K9nwuOvfkTtfECdp4riuduJkh6Dd42 0/UScIbelH/UX0ajgGV1XjzbnBVSRw+RiyyAzyYZ/beVx3gSW3ZcwzjAN7zEFHBnoTwB GXk3plMLm6zP9GGAk05JFmtaoH8UcC5iRJZVmuLICKv09jNtlhZyN3Iuc6iv84vLcHYC sbvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782166239; x=1782771039; 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=/lWcRJ9xv3vj+kuUslXqTMu2ZS1PDN9hlN/ZqmuvJzU=; b=JybM3MjcT15NoFIJhFY1VfeWrX254kN4fMaRQhoYPPwTFuqSNYukD3oXBUGZGlweca 3vJThhtj3lBt/BZoN45JG8gwu6lZ33qggLAlY9qrY8vIJCdxgCTaYA2BEerbiDlYStJ9 X7NiFNU9Fqmj9WImhNFdOwlWPQNlXIAwsQ8w6mmn95X2ijK9dvOrWck3J6ryq8DVvsy7 MxnkcaCQuxPrZMspgbmnHGDGdW4IO7U/RD8F3JredcacEzJvSpU/zstLeg99Ej/PDXcM fSPkHI/pxZN5guCHYYiwZA+rA9/McaAaRYla02jHjDTaoAF9f61NuzFmgXTeDTHBniqO jMCQ== X-Forwarded-Encrypted: i=1; AFNElJ9Ax4Azla0UeJgeAHvkuVRM0mSkJevkkHBYblzQx3xm0E8XQFcQFKSlNF6n/zKAPZmi562Pu5Z+UF9p0a4=@vger.kernel.org X-Gm-Message-State: AOJu0YzO3yHdiM6KPTR3Vcw4/HcbmLiAJc6P8LS6tr+ZYiwltsgAEOQL vpjmg0cc3KxnuargRpyMraGKv7o+hKhTqXA2yhRzrcsLSkKWB2vIJPGO X-Gm-Gg: AfdE7cnDtFHaYIbbKLtv/sj0xllEWZ3vVmuvm07OIeFVtFMRloajuLufSiDS7PP6ORV l+wv/KTtdPGZvy1XhOo4e2sCXgjmlziwuOYwyqp3JXgnW+8CsTTqZ6bvCZ6TvSG2aNRufoGIbo8 vRX7byOUoy8iIjgq3kGiNBMB3GHAhucF63Dw3ByCL5TsVuLOWjCZbahRacAECdTeiaSaaX6dAk3 78xPAYUfde80jJv6JW+06DmzOmpUq/fKKduOKPZnC3SU/HvDEGmFMl5AqrM0sCQ1UkEDtZiQbtM NBrUQfOTC2DJ5bMfNrvrxmpA7tNbKnjoU72OQSJKT6fgxsOlgPFL3kpq9rKPGcSGbvXyiShCCbn q50JN3Aqt8dUj9PqVFp4R101wc9qBiOm9/7Ve6sJlUjtprn1Lf/ct7zxsWUCwBE47gG+U4eFBK5 NLxwzQk43WOjdUDGTfmbs3nnOiX6IkVpFgSzQi2NGXbZYgY+crSfhzGg== X-Received: by 2002:a05:6820:c85:b0:6a0:f323:e967 with SMTP id 006d021491bc7-6a0f323ea6fmr9372385eaf.55.1782166239358; Mon, 22 Jun 2026 15:10:39 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:71::]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-6a0e9f77720sm5727019eaf.6.2026.06.22.15.10.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2026 15:10:39 -0700 (PDT) From: Joshua Hahn To: Yosry Ahmed Cc: Youngjun Park , Shakeel Butt , akpm@linux-foundation.org, chrisl@kernel.org, youngjun.park@lge.com, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kasong@tencent.com, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, muchun.song@linux.dev, shikemeng@huaweicloud.com, nphamcs@gmail.com, baoquan.he@linux.dev, baohua@kernel.org, gunho.lee@lge.com, taejoon.song@lge.com, hyungjun.cho@lge.com, mkoutny@suse.com, baver.bae@lge.com, matia.kim@lge.com Subject: Re: [PATCH v9 3/6] mm: memcontrol: add interface for swap tier selection Date: Mon, 22 Jun 2026 15:10:34 -0700 Message-ID: <20260622221037.255359-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.53.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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Mon, 22 Jun 2026 14:21:30 -0700 Yosry Ahmed wrote: > On Sat, Jun 20, 2026 at 11:17 AM Youngjun Park wrote: > > > > Introduce memory.swap.tiers.max, a flat-keyed file listing each > > tier defined in /sys/kernel/mm/swap/tiers with its state, "max" > > (allowed, the default) or "0" (disabled). A tier is one bit in the > > cgroup's tier mask, so writing " max" or " 0" sets or > > clears that bit. > > > > Since the current use case lacks amount control, it only supports > > "max" (on) and "0" (off). Therefore, it does not track per-tier swap > > usage, relying instead on a fast runtime bitmask check. > > > > We maintain both `mask` and `effective_mask`. The `effective_mask` is > > strictly bounded by the parent (e.g., if a parent is "0", the child's > > effective state is "0" even if its `mask` is "max"). Maintaining this > > separately avoids costly cgroup tree traversals to check ancestors at > > runtime. > > > > Suggested-by: Shakeel Butt > > Suggested-by: Yosry Ahmed > > Signed-off-by: Youngjun Park > > --- > > Documentation/admin-guide/cgroup-v2.rst | 20 +++++ > > Documentation/mm/swap-tier.rst | 9 +++ > > include/linux/memcontrol.h | 5 ++ > > mm/memcontrol.c | 67 ++++++++++++++++ > > mm/swap_state.c | 5 +- > > mm/swap_tier.c | 102 +++++++++++++++++++++++- > > mm/swap_tier.h | 57 +++++++++++-- > > 7 files changed, 255 insertions(+), 10 deletions(-) > > > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > > index 6efd0095ed99..4843ffcfd110 100644 > > --- a/Documentation/admin-guide/cgroup-v2.rst > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > @@ -1850,6 +1850,26 @@ The following nested keys are defined. > > Swap usage hard limit. If a cgroup's swap usage reaches this > > limit, anonymous memory of the cgroup will not be swapped out. > > > > + memory.swap.tiers.max > > + A read-write flat-keyed file which exists on non-root > > + cgroups. The default is "max" for every tier. Hi Yosry, Sorry, I feel like I'm joining the party late. Apologies if I'm missing some context or repeating a discussion that's already been had. Please let me know if that is the case. One quick tangent: I was chatting with Nhat last week about swap tiers and its relation to memory tiering. Nhat brought up a good point, which is that while both swap tiers and memory tiers provide a clear hierarchy of performance, only memory tiering allows for movement between the tiers. AFAICT, swap tiering does not allow for direct migration from a higher tier swap backend to a lower tier swap backend if the higher tier backend runs out of memory. In that sense, I'm not entirely sure if we need to enforce similar semantics across swap tiering and memory tiering; it seems like there are some fundamental differences anyways to how we treat these tiers. > I wonder what should the default behavior be if memory.swap.max is set > to a value other than "max". Should the limits in > memory.swap.tiers.max auto-scale or remain as "max"? We probably want > to keep the behavior consistent with memory tiering. > > Shakeel/Joshua, WDYT? I think that the motivation behind these tiers is different for swap and memory. Tiered memory limits is motivated by preventing one workload from conusming all of a valuable resource, while swap tiers seems more to do with excluding certain workloads from using performant tiers and ensuring other workloads stay on those performant tiers. IOW memory tiers exist for fairness, but it seems like swap tiers exist for workload performance tiering. But maybe there's a usecase out there that would want fairness to apply in the swap tiers as well that I am not seeing. If that is the case, I think auto-scaling makes sense but can be a bit tricky, since there is no universal tiered ratio; each workload will have different tiers it can swap to, so they will all have to calculate their own ratios. Tiered memory limits escapes this difficulty since we assume all memory can be placed on all tiers, so we have a system-wide ratio : -) Let me know what you think! Have a great day :D Joshua