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 88C92C71136 for ; Wed, 18 Jun 2025 00:32:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2676A6B008A; Tue, 17 Jun 2025 20:32:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 23FA36B008C; Tue, 17 Jun 2025 20:32:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 155A16B0092; Tue, 17 Jun 2025 20:32:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 04C946B008A for ; Tue, 17 Jun 2025 20:32:53 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 77F0D5F7C0 for ; Wed, 18 Jun 2025 00:32:52 +0000 (UTC) X-FDA: 83566646184.06.071CABF Received: from lgeamrelo07.lge.com (lgeamrelo07.lge.com [156.147.51.103]) by imf24.hostedemail.com (Postfix) with ESMTP id B1F47180012 for ; Wed, 18 Jun 2025 00:32:45 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750206770; a=rsa-sha256; cv=none; b=YiIc875xb6EhckHMZBFV7rAnLP0o/KzGw5O0Yax8SWMDiHOalC7wAIAV7HbAZI/zDucErA rGsOWTPnRssisjog1SCQ9L3IF4oZpGFwDmnLvZtFQEK04cIqQ+Yn5Vu7vSlHwkGQZ5Dr8B NdRvGMKecNdE8K2SDOXJWpPdxxtLRFI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.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=1750206770; 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=/OdKIguPO0Hc5K79qkRYC8b/2CWSUrYiiYfdXPQOfxs=; b=u5SUxFumXT9611vc+PSiW4Blt3v7EIKR8xc1oI1YtZMTRiTxDxRXoCbGnWv6VVasiQpnzU eZAD7VN8HQ4JUqKvuPsMxzGMvyKTX53HeqICuopvQ2pWCsmpHhkfcV02H+GLITcx64qC5j bbTTiKpuLS4b8t/r4mYLv/f826OY3+M= Received: from unknown (HELO yjaykim-PowerEdge-T330) (10.177.112.156) by 156.147.51.103 with ESMTP; 18 Jun 2025 09:32:33 +0900 X-Original-SENDERIP: 10.177.112.156 X-Original-MAILFROM: youngjun.park@lge.com Date: Wed, 18 Jun 2025 09:32:13 +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-Stat-Signature: dkynjshgc1iuxbe83u5i6i79yzgp7gjr X-Rspamd-Queue-Id: B1F47180012 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1750206765-718143 X-HE-Meta: U2FsdGVkX18b1kx9SLO9k0H49v5f38gs48R5SR/ZXB3Mh/z/gsGb/Bxesg0Po2YGo7E5DDOAoSu94DsTjtSID4aztjp3GwmOgcPnOJUaJo8TMVwUd7YxVpCGp3j8zH+Li6fVerl5bJV/5Zo+mrI+UBLiQsHqIvsh0GUW058q4TZb8fwUn4TO3vcDaKwMS6l9eccQrNZDoYWcoIUDhVHYt4Bi863dP8JoiMeOyFbr/pwd8y5W11GNeItMFARCAW0d90zzIEZWY0y4DOH4EeKTLG2z13feJjnFw9njY4xNg8dsJXdfzrfxDIgzfuieEkDBoxpGkeuitKtp/00RP0GH2YPq3UREX20dDBvcSxi+pXdxp5b57DmdJv6TWu8YaxIFQiwRYgmjmy7xd8x8uVdvRWn31D3C91YVS5q3zAMsif9nEGfGDbe4qBAJ/U02FDTIKj18a9gcwaUvjUZDa0aVPB4Gj8ZBBvpnJiJunEf8oa1uXCXEuJaqOR98vQSsvAHMtWZNNBWAjSw9WHVYM4xs3kpe6jExDBlKcjffpAMWyhlbeZQiAE1Prl7iGUJgR2rAYXsi/TV9sHZUYhvX9KqOiKfWKYslcYcaojpuu8AwVvuf30YooTDpNvj36YznIJae1nN7Ie4B8hhbOewRN+CbLWmRjMX+3oh7euik0gA/bX28WDdKReQQ65Vty/HsFupn5NOZt3lnVwV9Qxv+nuWGN1Jdy2l46kh9TMEr8w5kkIGyJEteVwhOezRqor+eiaokEICMN1wFKVlVb+indQQwdbkU/CP3ApBbnRuYdoMBoBxi61ARFZ/ojJ4RH90d7tdpznLSPwXfLZWKLEVdIffGqbiA6kHvKpsQvpRCULNCPlgVuHoCdpYNJ5CFwW6D9bO/F+hSam1HmwOiFmZlxocakhKbNGtANvfRwT/qCAuuooeQJxnOkrgFaoyAwkOhJHJKAiTnWZ9+yBxtvtRPznJ P0PhV0k9 RrMEkRlqUwCqEDiCf/STGtF2EdPVeMdd9gA7vr68xqj6+ERad0rDSRk4zldPQx9YRBtfWH4v/lgBzMZfG1P+7FBe61JSpHfLnf2P0uA40LXG+q5M93mx4GomMiqjF+U4d5Ne2BKB6y8qh2aEgne8rzqNCBeQ93wYSCMjwlvshsOZsXAB3FpwXOGoXlR0YgsmTNLKgi5FNqa5khemoP2Ft5gqK+xyy30XgCUvZXLEDvQEGX3JA1L7P7kmKvoiH+Ex8WfalT8qzL7Ubpl8= 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 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