linux-kernel - Re: [RFC PATCH 1/2] mm/swap, memcg: basic structure and logic for per cgroup swap priority control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bhcx37fve7sgyod3bxsky5wb3zixn4o3dwuiknmpy7fsbqgtli@rmrxmvjro4ht>
Date: Mon, 30 Jun 2025 19:39:47 +0200
From: Michal Koutný <mkoutny@...e.com>
To: YoungJun Park <youngjun.park@....com>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org, hannes@...xchg.org, 
	mhocko@...nel.org, roman.gushchin@...ux.dev, shakeel.butt@...ux.dev, 
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org, shikemeng@...weicloud.com, 
	kasong@...cent.com, nphamcs@...il.com, bhe@...hat.com, baohua@...nel.org, 
	chrisl@...nel.org, muchun.song@...ux.dev, iamjoonsoo.kim@....com, 
	taejoon.song@....com, gunho.lee@....com
Subject: Re: [RFC PATCH 1/2] mm/swap, memcg: basic structure and logic for
 per cgroup swap priority control

On Wed, Jun 18, 2025 at 09:07:51PM +0900, YoungJun Park <youngjun.park@....com> wrote:
> This is because cgroups can still restrict swap device usage and control 
> device order without requiring explicit priorities for all devices.
> In this view, the cgroup interface serves more as a limit or preference 
> mechanism across the full set of available swap devices, rather than
> requiring full enumeration and configuration.

I was wondering whether your use cases would be catered by having
memory.swap.max limit per device (essentially disable swap to undesired
device(s) for given group). The disadvantage is that memory.swap.max is
already existing as scalar. Alternatively, remapping priorities to
memory.swap.weight -- with sibling vs sibling competition and children
treated with weight of parent when approached from the top. I find this
weight semantics little weird as it'd clash with other .weight which are
dual to this (cgroups compete over one device vs cgroup is choosing
between multiple devices).

Please try to take the existing distribution models into account not to
make something overly unidiomatic,
Michal

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)