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 D6DC3C6FA8E for ; Thu, 2 Mar 2023 17:47:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C0726B0078; Thu, 2 Mar 2023 12:47:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 24A5C6B007B; Thu, 2 Mar 2023 12:47:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C37F6B007D; Thu, 2 Mar 2023 12:47:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EB59E6B0078 for ; Thu, 2 Mar 2023 12:47:12 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B6AC1120E12 for ; Thu, 2 Mar 2023 17:47:12 +0000 (UTC) X-FDA: 80524689504.03.358CCDF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id E956380004 for ; Thu, 2 Mar 2023 17:47:10 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GptuwjOc; spf=pass (imf30.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677779231; 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:dkim-signature; bh=ol9i6QMXxT9u0AcuOYI6KEse8kHj7w4NJZTInFp4WsE=; b=yVPmwS6kVtkwik4F/UwCK83FwCpsBWigKyR6MUymK0/TQXjff7XTFYemF417I/kfWNWb4p 2P2TD09NPCK7Mn7Zob2LQC3KfgsZXr2wLnht8w4LFmnhf3583dKK8vridtuQMWGcZSxdUy XQR4uWz9c6CsZ19ccmf0RbkaAshz6Q0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GptuwjOc; spf=pass (imf30.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677779231; a=rsa-sha256; cv=none; b=DVTxxUMvuxebrS4Gp7j5Xb+UYEHKr7ZFiG1RsDXy0WbVTfOUG6yj/cZQyJwI04EgHDdGaw BSNgkwEQ8HW4qYY6QaPGTeps13I+wxEisLkrmQ71QNUj3AosiQ9Bgi/g5yA91CW65qxk17 oPmfIqz9K39Zb9C8lHPaLArUvGJbVkk= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BA5B161620; Thu, 2 Mar 2023 17:47:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A7BDC433EF; Thu, 2 Mar 2023 17:47:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677779229; bh=gQkyS1EyqaKjPyM7f5FhtRRG+rNQOjYbKcDxHm5ENgU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GptuwjOcaaLw2k1mAU0nUnET57f5UCsuflaigPofwMKoDKXwjdSQUAK7ph+W+awHz cBo8LJx8+fS0WvIaaGp9ghgLVjIiSnRnfEuy0y0qFruJhp7X3yi2HK+5NcUWcMVn8w plCre2aDzhrdV5/yNRx9MeACZ1idH2lZY+EcYNrfYjRPlSv9AJ2DgwRxyQ+gPeIH2e uoQB+JIM6G0UgpCoZLflIfh0dTPFJJA7d8/aPd97KphUR3Guw8AZCoECjU4vgEJQPS Xt2VFVM8Sg3yNYSAWCuptQPrf79PJ9seJQ5pPTZ06r7my+G6JYDnRrzfGaJ0Ap+WtH y9lvsxgPgz1mw== Date: Thu, 2 Mar 2023 09:47:06 -0800 From: Chris Li To: Yosry Ahmed Cc: Minchan Kim , Johannes Weiner , Sergey Senozhatsky , lsf-pc@lists.linux-foundation.org, Linux-MM , Michal Hocko , Shakeel Butt , David Rientjes , Hugh Dickins , Seth Jennings , Dan Streetman , Vitaly Wool , Yang Shi , Peter Xu , Andrew Morton , Rik van Riel Subject: Re: [LSF/MM/BPF TOPIC] Swap Abstraction / Native Zswap Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: z4yxww6trhqurjbboi4hyrtqc7aza9ic X-Rspamd-Queue-Id: E956380004 X-HE-Tag: 1677779230-711937 X-HE-Meta: U2FsdGVkX1/fa33je/YQBp4yVlDAA9eFJULL/ZSo7URu9X7VtyEC+U1Kp2tk7nO2ixRiGFC3t06hMWShHAc30r4ne3Q1YcXeYHGesjGaDVcPAHuXxjAixChm4W3fsvOZxR1Fo/rziri5nhhq1/17FDM6lJyjzY0RxkjPFWS+8kDtHS18Mhq2SjjW1g+yBjmtqBiV9FygEvwQ91+DdCvEjehelsASrUF1jUjNuEHT8uyZ0gcM1geCrVbaPbXgHoe6Z/Mm4h2uzhp2fNbm3QKOZ1NmaNoq8nguHlKsnitZBudyZch+lpoeDC07BZVkpkW3cIuEXhg6Df9Q4fmzPYV9GY/Kt8QGJHLWn5kn2AOonEf4GPTN+HFip4krCl6RZlPY8qgTAzp8eG2+yw8gIG/GhPcwIvWdpWm5ItjExKGOVh87GRMfS/JLDbe7plmFyT8DXGqnWIP671ILrSfN+WLRLG6PEjxOCUOc+lMK2cBK0YF8y2OfODjtONWbWhmpScmKnnjz9V+yVqraKlGlcAW/a4c5bl9i5I9sczqtlPxfPytxpIievVvcksxhW9H/rDfvAA9mV4rOxdq/WbKoqDRvxAzMjjpofTgP8SFBd/CBzJ7KblWZPEMuOz4LgG1/n+wJQYsGYEFwSl0cFI5dD3DP/JtiD4sEp9at6VBbPvESmBE5Guo02QRjQS/hffaeWT6P3gtUE/92on6L3oQFZMfyS0W9gIL24pMG+AY8m/haEKQxx+H86X+72sb30/P0c39EDanDQeLa+mSGXCzcC/ndVaMeA9HDJa0u8E0Yi6ZmHR90nXHV3aGPmFv1pH8Mijdlr4i05Yq0y9LMds+so12ZcE96k1aaujbeO710/oV9hVHnffMH3pz20kKM8PwljzMnP9viYZj817p/5nBbKESBRsosh4vcAl2gmLqFuBu9Ud1zEN99rvz/CgPiOIT1SqjOaqO6UO7/UJOOBR8QjNS WZFU+iy5 AdA9CBeUB+uz0P41ub+m1a1kYkf3i8qHlbq70WWodmmpaaISu9m9fLwD+Qd4Dn4FfGqtRUuHsIKSlFr86A5j+6No9scV6z4+xdmZaoGBe9mRwYSOETfq/GY9jMiuc75LLcTTIcVynbv889cGRwfW7PmTJhjiN8uNUriRqamk3xkuOiGDtbya09OXrbx20ET1wr2IZ2Lzhs7ygO87lwS1YltTw2fZyGR2HkE/0eI0BW90pQFAA2ljw2WfFWJqj8467EK2/FjZoajl6UTV9m+YvpHfgnVtQDShYyyLUnewcc+XOPvxt0P1WXAvZeA== 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: On Wed, Mar 01, 2023 at 04:58:08PM -0800, Yosry Ahmed wrote: > > The indirection layer would be essential to support it but it would > > be also great if we don't waste any memory for the user who don't > > want the feature. > > I can't currently think of a way to eliminate overhead for people only > using swapfiles, as a lot of the core implementation changes, unless > we want to maintain considerably more code with a lot of repeated > functionality implemented differently. Perhaps this will change as I > implement this, maybe things are better (or worse) than what I think > they are, I am actively working on a proof-of-concept right now. Maybe > a discussion in LSF/MM/BPF will help come up with optimizations as > well :) How about we just put the indirection layer into the swap device? For the zswap, it registered its own swap device type, as many as needed. The indirection is that, it is up to the swap device type to interpret the offset and swap counts. Maybe it even has its own address space and address space ops. The zswap does not have swap_map and has its own xtree to look up the zswap entry.  The common swap device related operation can have some swap related swap_device_ops function call back. e.g. get swap_cout.  That way, obviously there will not be much memory overhead for the devicethat doesn't use zswap.  The zswap entry can still do something similar to your swap_desc, save some pointer to its nested backing device(normal swap file). That way the swap_desc overhead is purely on the zswap side. Chris