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 D4AF8C48BF6 for ; Mon, 4 Mar 2024 22:58:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 505CD6B0081; Mon, 4 Mar 2024 17:58:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B65E6B0083; Mon, 4 Mar 2024 17:58:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A5406B0088; Mon, 4 Mar 2024 17:58:29 -0500 (EST) 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 2CC146B0081 for ; Mon, 4 Mar 2024 17:58:29 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E8D1DA0747 for ; Mon, 4 Mar 2024 22:58:28 +0000 (UTC) X-FDA: 81860872296.18.497AE9B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id C2EB440013 for ; Mon, 4 Mar 2024 22:58:26 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KGBaAlKi; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709593107; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vquM2das4XkHeGNPDQ5BSGUdYa/3UszCkD6aYmwlH7g=; b=q/1QkZ2Foi5lz5aqWpwfYmTufHGKuR6dYetmGWEgPVxFVzvpXMbFrZVrk1s+4gqcSgjbaZ DaMe+Qz0p+BL65JCXCgtA+xp1xMu9b2QqxYTBCQli2ZRjBaX7WfoT3AtjGzBpRnnjF8/yJ h8MtHp267qtngsagvBXGHtDm0rwrgQ0= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KGBaAlKi; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709593107; a=rsa-sha256; cv=none; b=HoTV7iEhlt9k9kWSI3Zg7ojupfMcgaBRCvrvLhktgi/tG7L1K+/baMopUadCOWwATwrz6t DAGrzFt/M8QCMW939JmfMFiSLnYml9kBBTgfrjSMFHNZX9267VRjkhwRKHX1Vw7NLX90oX 8a3sIgqqO/RUlwmOcL9XA+pQQRRFnR4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vquM2das4XkHeGNPDQ5BSGUdYa/3UszCkD6aYmwlH7g=; b=KGBaAlKiR7JNN7AMGsX0rXg5n4 MAe2VL5GZv2QL7uyuSZqW44ZX55uggeTGHJTK+1oOGBpMngueJZpduWaIX5OjOHWnKL56O5XxzTZ6 47wd/cPbWxF3domtyuIjchpsmnJ8E+AJ8FcYlzkViFEETlUTAb+Lz77q1S3c9wgOj97JJPvTTXgMd pETBotkOy+KA4CAMLbYvNpaFCFa1ZN+UkORIC7eLYE3qfYeJM8jgFsas5M5zwvA1ebupzgk8iY85V fniKqYOr0mElTN7m4YU2yO2yAKV5JB+yMuh6z0tkmTdYFpUVknvocnZIM0riePGIJuPNvztk2iZZe MOzQyCRg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhHGG-00000002dNS-1FXA; Mon, 04 Mar 2024 22:58:20 +0000 Date: Mon, 4 Mar 2024 22:58:20 +0000 From: Matthew Wilcox To: Nhat Pham Cc: Chris Li , lsf-pc@lists.linux-foundation.org, linux-mm , ryan.roberts@arm.com, David Hildenbrand , Barry Song <21cnbao@gmail.com>, Chuanhua Han Subject: Re: [LSF/MM/BPF TOPIC] Swap Abstraction "the pony" Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: C2EB440013 X-Rspam-User: X-Stat-Signature: m3gp3o93k65uwn5g9sg1inkr8dkisgin X-Rspamd-Server: rspam01 X-HE-Tag: 1709593106-427486 X-HE-Meta: U2FsdGVkX1/APz9JMG5r1F9/p5bf6oZKYEqeuocP1Gn1WU/h7MMjsZG4JTvc6usPXyRMdeUeaY6fLlECytYnciJxxl/yref8F0xMSJD2Drx9UkxuEfgpRDDCKwO1UzztZ9g+AjfVmQMGJn4WT0RKRY+85IjTnGmK7dl4j93dvC+XWLHW1MLEceKn+dmhk9GRaBNHDrZn6Le6UGoa7pyj+ld3UJZyVJPSbsaLQnjNKBwe0VF30J8nHiHBlQHKjIaeRXKTqiPfC4sNAnmw3J2+Btsdm1h1J0f1LMqyi32UBZS9HfI4MURvoNc1FuFw9NCehShbKXRh/P1tJDUCbYdJdf3O2r1wy+MaqnviiuIvzefsg5jlR1sEOkhckNwc60hV1cRvHqanETfcLn8R2DXELnuWO9lB91Hmr18j+n9cIN4Jc1WPejCI5OCnM/LHiufsXEJEMF4u4eBClEumdpbMHuQQu0TmWlEXbXlefv9c1dii7exyv4Rqkv2N7yD9+ogmXoCIgBRTxFynSZcmTK+c0KcKM5haoTtsU7K5xeh3ZVa2eU4l6GgowQVVwUG2w8PX2tXtPLe2OZ/H4sEcqh93YuLtEFInJEhHnrd2qjSNqFjNxXyGbv2u3nlszc3jgJJgsbuB/LX9V0U8q01TaNG1skkXRsl/MB15Gf4ZlDQe+aRq5FGEb1h/tjNnDkA6MJFGxasNFcIlfSqdrGXgBf73bGOp/6GGa9H45xdPWlzFzdvW87ApctnPz3ZwmfQVfFjkJTO6c8NvWQPaZgc8PxkANvsecZ8HIIOT9cnAGjUsqMYm/zUwEHfpWorxMBta2Unj7zgGM/ziChvbSAAn5VNAqzkAztx4Eq2EZ9KQofY6M/YxZCnVeIDG+zOdxST07jlHCQAit2gpvbQmM5JyDdGE7Cr23l27LHTJo1NSzLqBxaLRilYsG23DGw9CysXHO8raV9I1B3rojw70gTUApkr Em/m7tXM Jh9ezdLPnQRT6rufu0S9O9jtvWc82fcFt426q4QPha9Xq22IC2g4RhBxn6AheN+Hg247XQM5krdQqM67SNiEAA9WRS4DBYcCR4hsvHcz/Rgj3sqSmbBERlW/eGs1IWrtBxgP8uh4xV5pnGek= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000991, 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, Mar 01, 2024 at 04:53:43PM +0700, Nhat Pham wrote: > IMHO, one thing this new abstraction should support is seamless > transfer/migration of pages from one backend to another (perhaps from > high to low priority backends, i.e writeback). > > I think this will require some careful redesigns. The closest thing we > have right now is zswap -> backing swapfile. But it is currently > handled in a rather peculiar manner - the underlying swap slot has > already been reserved for the zswap entry. But there's a couple of > problems with this: > > a) This is wasteful. We're essentially having the same piece of data > occupying spaces in two levels in the hierarchies. > b) How do we generalize to a multi-tier hierarchy? > c) This is a bit too backend-specific. It'd be nice if we can make > this as backend-agnostic as possible (if possible). > > Motivation: I'm currently working/thinking about decoupling zswap and > swap, and this is one of the more challenging aspects (as I can't seem > to find a precedent in the swap world for inter-swap backends pages > migration), and especially with respect to concurrent loads (and > swapcache interactions). Have you considered (and already rejected?) the opposite approach -- coupling zswap and swap more tightly? That is, we always write out the original pages today. Why don't we write out the compressed pages instead? For the same amount of I/O, we'd free up more memory! That sounds like a win to me. I'm sure it'd be a big redesign, but that seems to be what we're talking about anyway.