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] [day] [month] [year] [list]
Message-ID: <20251115012247.78999-1-sj@kernel.org>
Date: Fri, 14 Nov 2025 17:22:45 -0800
From: SeongJae Park <sj@...nel.org>
To: Youngjun Park <youngjun.park@....com>
Cc: SeongJae Park <sj@...nel.org>,
	akpm@...ux-foundation.org,
	linux-mm@...ck.org,
	cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	chrisl@...nel.org,
	kasong@...cent.com,
	hannes@...xchg.org,
	mhocko@...nel.org,
	roman.gushchin@...ux.dev,
	shakeel.butt@...ux.dev,
	muchun.song@...ux.dev,
	shikemeng@...weicloud.com,
	nphamcs@...il.com,
	bhe@...hat.com,
	baohua@...nel.org,
	gunho.lee@....com,
	taejoon.song@....com
Subject: Re: [RFC] mm/swap, memcg: Introduce swap tiers for cgroup based swap control

On Sun,  9 Nov 2025 21:49:44 +0900 Youngjun Park <youngjun.park@....com> wrote:

> Hi all,
> 
> In constrained environments, there is a need to improve workload
> performance by controlling swap device usage on a per-process or
> per-cgroup basis. For example, one might want to direct critical
> processes to faster swap devices (like SSDs) while relegating
> less critical ones to slower devices (like HDDs or Network Swap).
> 
> Initial approach was to introduce a per-cgroup swap priority
> mechanism [1]. However, through review and discussion, several
> drawbacks were identified:
> 
> a. There is a lack of concrete use cases for assigning a fine-grained,
>    unique swap priority to each cgroup. 
> b. The implementation complexity was high relative to the desired
>    level of control.
> c. Differing swap priorities between cgroups could lead to LRU
>    inversion problems.
> 
> To address these concerns, I propose the "swap tiers" concept, 
> originally suggested by Chris Li [2] and further developed through 
> collaborative discussions. I would like to thank Chris Li and 
> He Baoquan for their invaluable contributions in refining this 
> approach, and Kairui Song, Nhat Pham, and Michal Koutný for their 
> insightful reviews of earlier RFC versions.

I think the tiers concept is a nice abstraction.  I'm also interested in how
the in-kernel control mechanism will deal with tiers management, which is not
always simple.  I'll try to take a time to read this series thoroughly.  Thank
you for sharing this nice work!

Nevertheless, I'm curious if there is simpler and more flexible ways to achieve
the goal (control of swap device to use).  For example, extending existing
proactive pageout features, such as memory.reclaim, MADV_PAGEOUT or
DAMOS_PAGEOUT, to let users specify the swap device to use.  Doing such
extension for MADV_PAGEOUT may be challenging, but it might be doable for
memory.reclaim and DAMOS_PAGEOUT.  Have you considered this kind of options?


Thanks,
SJ

[...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ