linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: YoungJun Park <youngjun.park@lge.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev,
	shakeel.butt@linux.dev, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org, shikemeng@huaweicloud.com,
	kasong@tencent.com, nphamcs@gmail.com, bhe@redhat.com,
	baohua@kernel.org, chrisl@kernel.org, muchun.song@linux.dev,
	iamjoonsoo.kim@lge.com, taejoon.song@lge.com, gunho.lee@lge.com
Subject: Re: [RFC PATCH 1/2] mm/swap, memcg: basic structure and logic for per cgroup swap priority control
Date: Wed, 18 Jun 2025 09:32:13 +0900	[thread overview]
Message-ID: <aFIJDQeHmTPJrK57@yjaykim-PowerEdge-T330> (raw)
In-Reply-To: <pcji4n5tjsgjwbp7r65gfevkr3wyghlbi2vi4mndafzs4w7zs4@2k4citaugdz2>

On Tue, Jun 17, 2025 at 02:23:07PM +0200, Michal Koutný wrote:
> Hello.
> 
> On Thu, Jun 12, 2025 at 07:37:43PM +0900, youngjun.park@lge.com wrote:
> > Example:
> > cat memory.swap.priority
> > Inactive
> > /dev/sdb	unique:1	 prio:10
> > /dev/sdc	unique:2	 prio:5
> > 
> > - Creation
> > echo  "unique id of swapdev 1: priority, unique id of swapdev 2: priority ..."
> > > memory.swap.priority
> > 
> > - Destruction
> > Reset through the memory.swap.priority interface.
> > Example: echo "" > memory.swap.priority
> > 
> > And also be destroyed when the mem_cgroup is removed.
> > 
> > 3. Priority Mechanism
> > 
> > - Follows the original concept of swap priority.
> > (This includes automatic binding of swap devices to NUMA nodes.)
> 
> How is this supposed to work
> cg1     /dev/sda	prio:10
>         /dev/sdb	prio:5
> ` cg3     /dev/sda	  prio:5
>    	  /dev/sdb	  prio:10
> cg2     /dev/sda	prio:5
>         /dev/sdb	prio:10
> ` cg4     /dev/sda	  prio:10
>    	  /dev/sdb	  prio:5
> 
> when there are competitors from cg3 and cg4? Which device should be
> preferred by each cgroup?

Hello Michal.

What issue is the question assuming the existence of competitors in two
cgroups trying to address? Could you explain it a bit more specifically?

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.

> Interface note -- try to make it "Nested keyed" or "Flat keyed" as
> described in Documentation/admin-guide/cgroup-v2.rst (like io.max or
> io.weight), so that it is consistent with other cgroup v2 APIs.

Yes, it looks like the API format should be adjusted as you suggested.
Thanks for the review.

Regards,
Youngjun Park


  reply	other threads:[~2025-06-18  0:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12 10:37 [RFC PATCH 0/2] mm/swap, memcg: Support per-cgroup swap device prioritization youngjun.park
2025-06-12 10:37 ` [RFC PATCH 1/2] mm/swap, memcg: basic structure and logic for per cgroup swap priority control youngjun.park
2025-06-17 12:23   ` Michal Koutný
2025-06-18  0:32     ` YoungJun Park [this message]
2025-06-18  9:11       ` Michal Koutný
2025-06-18 12:07         ` YoungJun Park
2025-06-30 17:39           ` Michal Koutný
2025-07-01 13:08             ` YoungJun Park
2025-07-07  9:59               ` Michal Koutný
2025-07-07 14:45                 ` YoungJun Park
2025-07-07 14:57                   ` YoungJun Park
2025-06-12 10:37 ` [RFC PATCH 2/2] mm: swap: apply per cgroup swap priority mechansim on swap layer youngjun.park
2025-06-12 11:14   ` Kairui Song
2025-06-12 11:16     ` Kairui Song
2025-06-12 17:28     ` Nhat Pham
2025-06-12 18:20       ` Kairui Song
2025-06-12 20:08         ` Nhat Pham
2025-06-13  7:11           ` YoungJun Park
2025-06-13  7:36             ` Kairui Song
2025-06-13  7:38               ` Kairui Song
2025-06-13 10:45                 ` YoungJun Park
2025-06-13  6:49     ` YoungJun Park
2025-06-12 12:24 ` [RFC PATCH 0/2] mm/swap, memcg: Support per-cgroup swap device prioritization Kairui Song
2025-06-12 21:32   ` Nhat Pham
2025-06-13  6:56   ` YoungJun Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aFIJDQeHmTPJrK57@yjaykim-PowerEdge-T330 \
    --to=youngjun.park@lge.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=bhe@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=chrisl@kernel.org \
    --cc=gunho.lee@lge.com \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=nphamcs@gmail.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=shikemeng@huaweicloud.com \
    --cc=taejoon.song@lge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox