Message-ID: <aFKsF9GaI3tZL7C+@yjaykim-PowerEdge-T330>
Date: Wed, 18 Jun 2025 21:07:51 +0900
From: YoungJun Park <youngjun.park@....com>
To: Michal Koutný <mkoutny@...e.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 11:11:32AM +0200, Michal Koutný wrote:
> On Wed, Jun 18, 2025 at 09:32:13AM +0900, YoungJun Park <youngjun.park@....com> wrote:
> > What issue is the question assuming the existence of competitors in two
> > cgroups trying to address? Could you explain it a bit more specifically?
> 
> I'm after how this mechanism is supposed to honor hierarchical
> structure. (I thought the numeric example was the most specific.)
> 
> > 
> > To answer your question for now,
> > Each cgroup just prefers devices according to their priority values.
> > until swap device is exhausted.
> > 
> > cg1 prefer /dev/sda than /dev/sdb.
> > cg2 prefer /dev/sdb than /dev/sda.
> > cg3 prefer /dev/sdb than /dev/sda.
> > cg4 prefer /dev/sda than /dev/sdb.
> 
> Hm, than means the settigs from cg1 (or cg2) don't apply to descendant
> cg3 (or cg4) :-/

I've been thinking about whether the use case I suggested aligns with the
philosophy of cgroups, and I believe there are two feasible directions
could take (This still needs some detailed refinement.)

Bascially on two strategies, child inherits parent setting.

1. Preserve the order of priorities and type of swap devices
when a child cgroup inherits values from 
its parent. the inherited order must be strictly maintained

e.g 

1.1 possible case.
1.1.1
cgroupA (swapA-swapB-swapC)
	' cgroupB (swapA-swapC)

1.1.2 
cgroupA (swapA-swapB-swapC)
	' cgroupB (swapA-swapC)

after time, modify it (swapD add on cgroupA)

cgroupA (swapA-swapB-swapC-swapD)
	' cgroupB (swapA-swapC)

1.2.impossible case.

1.2.1 violate the order of priorities rule.
cgroupA (swapA-swapB-swapC)
	' cgroupB  (swapC-swapA-swapB)

1.2.2 violate the type of swap devices rule.
cgroupA (swapA-swapB-swapC)
	' cgroupB  (swapD)

2. Restrict child cgroups to only use values inherited from the parent,
without allowing them to define their own setting.

e.g
cgroupA (swapA-swapB-swapC)
	' cgroupB (swapA-swapB-swapC)

after time, modify it (swapD add on cgroupA)

cgroupA (swapA-swapB-swapC-swapD)
	' cgroupB (swapA-swapB-swapC-swapD)

it is different from 1.1.2 case swapD propagated. 
(because child and parent must be same)

> When referring to that document
> (Documentation/admin-guide/cgroup-v2.rst) again, which of the "Resource
> Distribution Models" do you find the most fitting for this scenario?

I initially submitted the RFC from the perspective that each in-use
swap device must explicitly have a priority assigned, including propagation
at swapon time. (for avoiding swap-fail by using this mechanism)

However, condisering the resource distribution model you mentioned, 
I now see that not requiring all swap devices to have an explicitly defined 
priority aligns better with the broader cgroup "limit distribution" philosophy,
particularly in terms of limiting and distributing resources.

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.
 
Regards,
Youngjun Park

Powered by blists - more mailing lists