From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC9EEC71157 for ; Wed, 18 Jun 2025 12:07:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69B0D6B0089; Wed, 18 Jun 2025 08:07:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64BD76B008A; Wed, 18 Jun 2025 08:07:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 561D16B008C; Wed, 18 Jun 2025 08:07:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 434346B0089 for ; Wed, 18 Jun 2025 08:07:59 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A97731614EB for ; Wed, 18 Jun 2025 12:07:58 +0000 (UTC) X-FDA: 83568397836.14.10BFB53 Received: from lgeamrelo07.lge.com (lgeamrelo07.lge.com [156.147.51.103]) by imf13.hostedemail.com (Postfix) with ESMTP id 45FA020015 for ; Wed, 18 Jun 2025 12:07:54 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of youngjun.park@lge.com designates 156.147.51.103 as permitted sender) smtp.mailfrom=youngjun.park@lge.com; dmarc=pass (policy=none) header.from=lge.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750248477; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2FKrTwnhdyVpfcXRG7DkPA24KmdHaINlbMGxRNcQeG0=; b=W8eIB4rmtELbUx8zkeP2NUnTnZXJ1eSvMhnvZk3qEgjNXb2BfACFTVxgZ4UrFxt2vWiNIW 52ckJv68C/LC8scUJOO2MJ6qQYQtIoOr3j2YUhclOl57RF+XkG0oKnLVfRiiTkje9+noxH EFCETsdfcy7AU0FastfpjH2ib6Dwv0Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750248477; a=rsa-sha256; cv=none; b=ydA6leXqt5Mh6iUFoM9IwG48c3varzNvUNdWFQswVGZFUQxxgjmK6YMgvhLYdea0QOY8NN pol0f39lwL11qVTnL0btBVjFsWC0gSe1fgHcrcK+c66KemO7mKDDXhAjN1ya7Gd4RoJXUv uhD3mcofXXQ1bfxiP95ezkrT6F9GNiU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of youngjun.park@lge.com designates 156.147.51.103 as permitted sender) smtp.mailfrom=youngjun.park@lge.com; dmarc=pass (policy=none) header.from=lge.com Received: from unknown (HELO yjaykim-PowerEdge-T330) (10.177.112.156) by 156.147.51.103 with ESMTP; 18 Jun 2025 21:07:51 +0900 X-Original-SENDERIP: 10.177.112.156 X-Original-MAILFROM: youngjun.park@lge.com Date: Wed, 18 Jun 2025 21:07:51 +0900 From: YoungJun Park To: Michal =?iso-8859-1?Q?Koutn=FD?= 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 Message-ID: References: <20250612103743.3385842-1-youngjun.park@lge.com> <20250612103743.3385842-2-youngjun.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 45FA020015 X-Stat-Signature: buxfrjfbnrmkr9z1ini7odspbo44aarb X-Rspam-User: X-HE-Tag: 1750248474-708949 X-HE-Meta: U2FsdGVkX1+PPTS4s7DGm2stP5pBixQXpm/Qsm6RUAlV9ci2KT7CwnzXGPIySD5TFKG8OsWShBh7e0GqhcLfOiWwqvlxPCwzW0fdHmUpVciMpqQNJOZwZovTTMatbXxJfENStAbKoy1vHs8D5PXqFwxgWUPtupY5j9YJiNHb7sTbkVyf+ncXq5tjqQXbOQ0bswnm0Tq4GS3ZaW6593nCv9UXZkTSCUsLSbToPOansI5kxqRzDT84prk173PGQuqljaHIdgcF8afZW9RlgsSdeIRZhs8zzJLu5Ks6CsNUcqxP01gE+n5++hbx+TZUs/lSz/anMeZOPhGkUX33N1P+HMH843Ye7ZI0lgnIehNlnO0IJPbKPa/yDLbIZtUNQ7S291Ae7A4HmHmmNAMguCkchjuosqOQh13F2jMRmbZILN/DozZ3RadClvC5Y1R7ulfQh0tZTvxc2boQI/TPKclXz3k3EuVe0piFtuxcgbL2YbjA6+hk8Dy/Wg2ikbHdPgq59H/rICMfzzz0cKeOg30joG2+jv9QAYObh2xCgZgkQgIMN/RP6eNxRr9kE9WRlfSf++IuDts3fA79mAGRQjhl7tlz3q5U5CUQZ4K1g72U38pil0AmdZgphn3gXwIHQapjV+ab8JJN7UMgF77nxnSpHB/2cTrNOVLU/d8liexxwL0mpA5k15O2YW+AJEaseAHdPxJP8UJFMUiiA35u28zMf8dRWmnuZ/rcAis3uVrMifc3fwBf7b9/9RCCAED10mk1HavSmPBRo6lPPMY3EDeplCFAKvA9wRHZHVaCedXa5dpNKLgntwsPIJpLyM83g4dePLifFlAT+MbWLdDQR3JT4TVn61Oq5HQVPhYjrp14+IHdImj5v6GiDG6V1JtTf3xQ3A4BA1ATDHD7CiDef12gpoehqRQCKuratfaa6ZN2Ll9oZfefQy3iVZtp8Bprh2/9ZhtPUEr3Yza2Tdn6xwW W7KahJZg m+upWez+LaubHm078unfUNJTNCYyaINN+FUheLSbIZoL6cyhxFA3dNOIFEJ1IVf/o3/0AIIZBaMFDESO9rLkUJjHgzWYBeDPxGd1FEHWiuDBIG/SdgmrR2cU7Pgmb09nJHE3uT05e/JZvW2SOzq0K7EIqWq1UVuMNxmI26HcQbpz4uEoVyRa/uQPjXLe1/9CToEyqTZtCjAGSfVxRn97LKkaIv2+8YNhnTlyGMIr+9pR7o6eOj6vBEbfMJRxi43n1jF8d0W7Vp08gV+0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 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