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 AF73BC4332F for ; Mon, 11 Dec 2023 22:55:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 481BC6B024F; Mon, 11 Dec 2023 17:55:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 431CF6B0250; Mon, 11 Dec 2023 17:55:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F9B46B0251; Mon, 11 Dec 2023 17:55:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 217B56B024F for ; Mon, 11 Dec 2023 17:55:50 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F03761A0690 for ; Mon, 11 Dec 2023 22:55:49 +0000 (UTC) X-FDA: 81556046418.09.7A18BCE Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by imf23.hostedemail.com (Postfix) with ESMTP id 279EE140004 for ; Mon, 11 Dec 2023 22:55:47 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="KS/JwK4l"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf23.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.167.182 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702335348; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jR8cUnQxE8Fxjjkvko5Z57/p4/4j9l8gY2eevyVTgGg=; b=IeJeE8v5sVtBhUvXX1nTb6sB4LWI1Gtg9eEGuzryhb+RjaDFil+tXWRLSOE1n4q5+6SpLl LY8/NNZmXPTLZljjLZkHmJfXmem2YnbVAK4Iqnf3MrwUdezh/6Xn+w+66eizAI2EM26Hdp I2crx2VDjYb7eMJ3HIC0YXPzNEw9ocU= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="KS/JwK4l"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf23.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.167.182 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702335348; a=rsa-sha256; cv=none; b=k1dLY8k6nAb5L6nJq0IjGVPvpWhtMO99DylUmlEfIoQf8oBRmscr/m3WgHGQXw3nDMwKam L47YimKZO963cjQViSU/7iwPsrsdN11BEr//7kLeLJZqdYZat4yEcZ8cm2bxge8wdrQgIf XU/elGq7uuDzt6mV78wCgGldnBVLLuE= Received: by mail-oi1-f182.google.com with SMTP id 5614622812f47-3ba10647a19so826695b6e.3 for ; Mon, 11 Dec 2023 14:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702335347; x=1702940147; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=jR8cUnQxE8Fxjjkvko5Z57/p4/4j9l8gY2eevyVTgGg=; b=KS/JwK4l8YRYKWJYiEB8PGxpwgQqt3vZvlFn8j03bKLB1mpEDYpCkIXG2rS4HocF5Z d7oWbym/j08MDzSCg7Zm3xUtMrnxxz+OXZ4pprv6qT6b1XSe2C+xP49S6PKBml1WpvU8 3ys650m9EWmxrpZoY5s47ta4JmaWJ+hEe6xCg35fdsS4pYAO4rsyUA71imaHPiPsK2H8 XJAk4prJ/R+lL7rmgIiFD5d7CWFSyibL9VTh1YoPW76xi4AAnqJC6Ctm/nRn8de8Fcu5 4qO2V1WpPrGT0gcBmWKx3dokVskSXoojMNusk5VQOGxYr/xi2RfrLJ+TZUn8KQEZyZxc kMRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702335347; x=1702940147; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jR8cUnQxE8Fxjjkvko5Z57/p4/4j9l8gY2eevyVTgGg=; b=ZTDKyBYpIvdlWj+yvK7/6uHvIlgBVYJcpWtAn2k/3UMcuEcm/C3AA4qzrFnioRt/EA 29EOObYmUY9bMw4N/vewvFCem+ZtVCok7S2k6uPHMdMNUEoQmuTes/oBPLLu3oBUq82v L5nEwEGr6LizRofnqA2+LfdoXox49Li5i2khUvbnGkJFz5baDxJvpp+tEwcwvShJh7k6 hIj4NL3fB3BdNDPDzw1BDbGc5yyPeVvDD8HQrewkefiNd1yyMPKxn8SIWFPSAsKXYt2l shLWeoKW1l3mzWu3HSZKotcmy4a9+wzfr158iK6FNIwkvcSWfp9pPGP2rvnTcWHTDzJm ac4A== X-Gm-Message-State: AOJu0YzobcWBT1Tbb9oXx0tKtKIhLvHRNSCOWWICjrfxWOr2HF0/P5Jy qmdRQNmU/6yHVCKVPeb2GQ8= X-Google-Smtp-Source: AGHT+IHDuAZTdcpV4XmlTA7uKfI6uuIRe4lg1MZit6+j+D1VUZEhU7umSXUI8zWgVm0W+j1ePT9gJA== X-Received: by 2002:a05:6808:1704:b0:3a4:316c:8eeb with SMTP id bc4-20020a056808170400b003a4316c8eebmr6901931oib.40.1702335346953; Mon, 11 Dec 2023 14:55:46 -0800 (PST) Received: from google.com ([2620:0:1000:8411:f6ed:4bc3:49fd:2063]) by smtp.gmail.com with ESMTPSA id s16-20020a62e710000000b006cb4fa1174dsm6792664pfh.124.2023.12.11.14.55.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 14:55:46 -0800 (PST) Date: Mon, 11 Dec 2023 14:55:43 -0800 From: Minchan Kim To: Johannes Weiner Cc: Chris Li , Nhat Pham , akpm@linux-foundation.org, tj@kernel.org, lizefan.x@bytedance.com, cerasuolodomenico@gmail.com, yosryahmed@google.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, hughd@google.com, corbet@lwn.net, konrad.wilk@oracle.com, senozhatsky@chromium.org, rppt@kernel.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, david@ixit.cz, Kairui Song , Zhongkun He Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling Message-ID: References: <20231207192406.3809579-1-nphamcs@gmail.com> <20231209034229.GA1001962@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231209034229.GA1001962@cmpxchg.org> X-Rspamd-Queue-Id: 279EE140004 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 66wzmpgaoogtoarafgwxbszib7rt9grc X-HE-Tag: 1702335347-843459 X-HE-Meta: U2FsdGVkX1+ecGXFpIOsCcWteenzlPmCAHATqYuWp4mPEAgGzW1K8nBMx1IxuYOJqDGXC8rx6FibJp47bFpshJhbeC/firD2LzQX3v0ADDVRaMdMMxQp8jejoHq09oYMnX0nUu0kbBeMqqtmftR20HnYBPdlDxu/dEm49XTYafrgW+v3Bv3V8T7/wobDq2Ssfd81aGyYHnOgBsWB5U5hDriuCALzYFtVSJesERA4p3OkfWPEW4B6urSdGuNrQQ+G0vq+ZBlYuMSQMMzALn2nl5kP1TFibJ8Z3oQPVAu2xZ87oqBDOOGDt4lnOMbzNOR4r38uKBQj6ehShMrMEEphoj/Z9LL2nMhQqApwEzj6EEU1XINigW0Wcz8B/SkwVCPY08hGGipibYkK0dxYT12BSI9UloJHZyIYo5R3Dtb5QIrGQUfiCsXk5JrhuilSBcDNAU4RZ6DA7Umq8D1BjxRu5rEwqyIopPRYlcJmSueX+A+OLAeJVY9sNmzg2OVqea88sllEge0pBpeWmIi8KKGkVrpAYaZYWxOmPb2/H0j9xfEkJbx9AqgMTedbx3LlVb3M4sVl6xrq+Tn5BXGtrVbU5raKSY5EL8G3IsCuMyysgFHmbeO6umq/tcHcZXjK4A/BdrtkmRxNz7FUtnSW5hsAz1fMJlfANuiIE/j3TsuRKXsRiuMjX3AuP0aHOZT8u9AMmM+xJ5BFL2PXcH9hteIDx31JkD42tmhjasglnZikhuISyjtwh2Lva0QJGE7WFEi+OFslqfE8ed9XTftkGzwJxF2S819iWUsXR8gT2BzIr3+rWCEx3sBPphLNkSR7vI8M7syAeyu2CAIOHmjA4ykYqdoGND5qs4eucPJVJe3CWv6JQwSsyeFVlB5yxZb2NyFCR7SHssTSeydAsj9VEnmqrCm3C/aGDwwqUM1LvC7/WLrm8yYs4qxvrHuSFey26aKGBXkCEzNV+oz90HDYnF5 1t2WYiGX w8tl91bpW97wopzZDT4NI/WPtxSqvzxdYKyOnABvdusmCyAvxLJWGyyrYlsnmDc5PXIXnD5E2foWWNBedeXPD2vfY3Q880MyARAjnmmuEIY73SLGmb9VtT/1RA3qAEuFU9EvJDWM/KEGnxeRgzdz7LIPEG0jeqp7kek11yR+dpoBq3IEAr7TLreDsE8dZI5E9uvG4+ugB1sU3hwCjzLRZFo+VQl9eP5VMHdfNO67pNBq+zh9tbuMdX4FC1IbCFXsbEx95whPUgjwERDn5WkGheTTmKGVS70Dvgt3DVrAUk0lEk8pmw46AZPkuaq9dyehHGlagT6sJxhXoKE4mPZnFjmpstoeLOmxWPfGhb+/lhfcfnOyYhrD+l23w/xsQYscjhAHJmjKYq9ye091THZhC8xXbAzYigT3JkzBWIDPMxS9W2CipUNqLTSq6h0RKn2hXHyhpAS8Pmsio/Od/VopbM+MZhqwTViNDGyEO/hGYEU71NJljwm5iS7/WmLBqkO29wlWDMqV7S2/M2fy0+DCIwuU0UtEYJCvH302FTd27KzhdB1ijKHF3DNLqVim3f7XFkktY8XcoVUObwGICYF7u5xgPBnIyWKwCDnuTp6JDF/fDtSHJD/NuvP/1hK4/evDm0/U3WShyM3blJQKvN5nwva4yyWt3urBRZmr60UrScOmbXw9ajK0j4IpZfQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Fri, Dec 08, 2023 at 10:42:29PM -0500, Johannes Weiner wrote: > On Fri, Dec 08, 2023 at 03:55:59PM -0800, Chris Li wrote: > > I can give you three usage cases right now: > > 1) Google producting kernel uses SSD only swap, it is currently on > > pilot. This is not expressible by the memory.zswap.writeback. You can > > set the memory.zswap.max = 0 and memory.zswap.writeback = 1, then SSD > > backed swapfile. But the whole thing feels very clunky, especially > > what you really want is SSD only swap, you need to do all this zswap > > config dance. Google has an internal memory.swapfile feature > > implemented per cgroup swap file type by "zswap only", "real swap file > > only", "both", "none" (the exact keyword might be different). running > > in the production for almost 10 years. The need for more than zswap > > type of per cgroup control is really there. > > We use regular swap on SSD without zswap just fine. Of course it's > expressible. > > On dedicated systems, zswap is disabled in sysfs. On shared hosts > where it's determined based on which workload is scheduled, zswap is > generally enabled through sysfs, and individual cgroup access is > controlled via memory.zswap.max - which is what this knob is for. > > This is analogous to enabling swap globally, and then opting > individual cgroups in and out with memory.swap.max. > > So this usecase is very much already supported, and it's expressed in > a way that's pretty natural for how cgroups express access and lack of > access to certain resources. > > I don't see how memory.swap.type or memory.swap.tiers would improve > this in any way. On the contrary, it would overlap and conflict with > existing controls to manage swap and zswap on a per-cgroup basis. > > > 2) As indicated by this discussion, Tencent has a usage case for SSD > > and hard disk swap as overflow. > > https://lore.kernel.org/linux-mm/20231119194740.94101-9-ryncsn@gmail.com/ > > +Kairui > > Multiple swap devices for round robin or with different priorities > aren't new, they have been supported for a very, very long time. So > far nobody has proposed to control the exact behavior on a per-cgroup > basis, and I didn't see anybody in this thread asking for it either. > > So I don't see how this counts as an obvious and automatic usecase for > memory.swap.tiers. > > > 3) Android has some fancy swap ideas led by those patches. > > https://lore.kernel.org/linux-mm/20230710221659.2473460-1-minchan@kernel.org/ > > It got shot down due to removal of frontswap. But the usage case and > > product requirement is there. > > +Minchan > > This looks like an optimization for zram to bypass the block layer and > hook directly into the swap code. Correct me if I'm wrong, but this > doesn't appear to have anything to do with per-cgroup backend control. Hi Johannes, I haven't been following the thread closely, but I noticed the discussion about potential use cases for zram with memcg. One interesting idea I have is to implement a swap controller per cgroup. This would allow us to tailor the zram swap behavior to the specific needs of different groups. For example, Group A, which is sensitive to swap latency, could use zram swap with a fast compression setting, even if it sacrifices some compression ratio. This would prioritize quick access to swapped data, even if it takes up more space. On the other hand, Group B, which can tolerate higher swap latency, could benefit from a slower compression setting that achieves a higher compression ratio. This would maximize memory efficiency at the cost of slightly slower data access. This approach could provide a more nuanced and flexible way to manage swap usage within different cgroups.