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 01E57C678D4 for ; Thu, 2 Mar 2023 18:15:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DEEC6B0071; Thu, 2 Mar 2023 13:15:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78F676B0073; Thu, 2 Mar 2023 13:15:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 630AE6B0074; Thu, 2 Mar 2023 13:15:37 -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 5533E6B0071 for ; Thu, 2 Mar 2023 13:15:37 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 19530A02BE for ; Thu, 2 Mar 2023 18:15:37 +0000 (UTC) X-FDA: 80524761114.07.B2B1CF7 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf02.hostedemail.com (Postfix) with ESMTP id 0947780015 for ; Thu, 2 Mar 2023 18:15:34 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=gmc8IM82; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.179 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677780935; 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=HiPrIsg4zrUXV3QMI03a2RavmUZdV2JnUSJSzYd/03A=; b=rDHG1E8hpMgvT1l+0SCXnDGeBIg1BhMisHumnBD0inPBjrpSRTdreiRp7oLliD6uODHfkO bQiO8AslRe0O6D9nnf9cEmsvmwdV7DISBt4e0VYPyRrk6KqTv701gpVZe/47Q7OleJSANV XmoLtk8aJPsJo9DfsuxKqk4YY+KL8YQ= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=gmc8IM82; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.179 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677780935; a=rsa-sha256; cv=none; b=NcVbsvzMTUb/B/kBlEEGHYIO0kgNqp5zDcLQyhSx7qLsgnilFv7r2KOJo8u9X51JLIIfmW 1omd7LGoC8B4WuI85WlJ8yy94EpSXP8fYiv3ZwWzeQYUkFnSv0RbQkH+x42PQskNdSTk0T BSpasE4KnIT0Tqoyd+lXieTfdW/atfA= Received: by mail-qt1-f179.google.com with SMTP id y10so208928qtj.2 for ; Thu, 02 Mar 2023 10:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; t=1677780934; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=HiPrIsg4zrUXV3QMI03a2RavmUZdV2JnUSJSzYd/03A=; b=gmc8IM82HnqxFcbDlVDeohNpvZm620jmDxru1B1z9a2laQ2dPJO+pkg1i4w2js1WaJ 8PfIqWUjAlBsYeKaAnd0ztYdESkhzMfPPRSKiKaVdER6aCGszjC2/675qdlKO6d4i7Cz hoorrqdaPbEOQsZD/jLDVjKgj3m/BL4Ucj23xNSi2tf8LWQDatPg5M6KnO9vulAdzBt1 OjI8B2pQ5Hjl46NC9XLbSe3OwodtOiAgOzSL1wHuo+b7Xdx7sZA+juKKa9uu1mGs41LA YTx233RvMlX9vozSEnbmEvZsz0Ji4Tpj42Hei/fkLZCTUEv5BnYnLYcDGc3O2lW2FCEJ 8HJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677780934; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HiPrIsg4zrUXV3QMI03a2RavmUZdV2JnUSJSzYd/03A=; b=a8x1zd8RUTJxluwQTSSj2wM0+yxmG3t88jaO8NsDvV6EJ5NmPyWUmhkTNkCcR6//ir Rl5/w22IwjUp1LY8JY82PZr/QfA54beWeXI6jAbrr5Wmbc9prZUb33VnvNukQoTxuJzk rmXAajAwX5o/4DbKt/LeVvigB6gCENF7ioEMeceNAjgr9zadXmoS6tc0watFuHWIY8UB uFHLkcIxq9lfzYWEtHhCKqhVKHYftB4mgfczCuP8CqIp1sVg5hGrs5+ObV6Nxl+lNVi1 Dw+WP2Pa5J7tARrYeWQVKnp9gz/XzqNGwNp9jdKpSgvwgeQVT4zvEMcb2UeboP+kdWtX HrcQ== X-Gm-Message-State: AO0yUKWVbtrItP4VhJjVkuXenmO72kpn6P9Wk8/xXsGy+h8hzuqLdeTj E1RBAYYgPDAI8U5/BPe9HkMM2g== X-Google-Smtp-Source: AK7set8RHbUddrrweSC8v7RoLQIPEyGuGTqDDn6lE90DBFPMJB2t7mHYqQfSqrLl+r+skmCGrxfp1g== X-Received: by 2002:ac8:5aca:0:b0:3bf:dd4e:3426 with SMTP id d10-20020ac85aca000000b003bfdd4e3426mr19410941qtd.64.1677780933986; Thu, 02 Mar 2023 10:15:33 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:19d]) by smtp.gmail.com with ESMTPSA id x12-20020ac84a0c000000b003b62e9c82ebsm140949qtq.48.2023.03.02.10.15.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 10:15:33 -0800 (PST) Date: Thu, 2 Mar 2023 13:15:32 -0500 From: Johannes Weiner To: Chris Li Cc: Yosry Ahmed , Minchan Kim , 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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0947780015 X-Rspam-User: X-Stat-Signature: 45o1fam8uyg8qa5pc84fp6p5gqcijnyh X-HE-Tag: 1677780934-644393 X-HE-Meta: U2FsdGVkX18zVibGP6ANqcMEJaDWYBMqa2uk69ji8oskAK/H1P0G0qNQLaz1AWoqLUEqPWyXzfzL30BBLGVRdtapjo5lsYNJILxamg+TpUhfDSP6IhKf8JhGWecm3aTq2/2oBa+qw4Y9uWa58nSoydLmDCPB3tLsECmbjq518LnND3kwJKdxjoJ/DlorpaU8jaEWewzu/zw2K/HGUVnKVwBnVkyPw0MGeckPvyQ0GwUyor2lVkR6gB3i55OLqXPG1Zc09tikWsaKl10EHIMBkofvp6oeZ21LnPNuAisAvCepcCs/sTlhiUoPd9FsY94OU+FJLyTLcgZJ1y1N3Ar781LEo09b2JFFYC/0JbbLa8pKDSZMa/AX5cqM7nM/qvak1CG3ZrjjXrX1/YYq+xmPnSIKygbyuN3GqCTKtDOvBJ11wmANvtSmFwE3pS7lbmvdai5AEudadDG9HJn7D55DYoEqf845vHQVqghh9aKiaVQ68fTkIIHIY9QO3hlPJY1G1kA/eTcBxhYLVe7T3XfeUTKSNAEjbY7+qtfJfmkn/rAfdlLW5oPD0KJOKQxx7WSyOqAc3Ku2jXllNFxh3dANV8LK3CdD82+2LKi9oRsspKxbQlQkKomEXMNpTANjppFlcnjKRz64xsehDxl0SH9jKF8YsMJgOJrloGI+WCLGhEHywmC+l/7qfuY+nuHWQM+5s2uzELeD2h63oTvcX09So8iFyzPNPbh6EhipIbuevuc/D5Xw3TFrTk2K7rbgoZ0fOkbPA9p7n67t6oWboPP1rd6elagY5ED2pYYjPUJZ1F2iHBXkIt6JG7s7oZ19KzLwz82N7ykQiXbvKAHytwS0HI29F2un/NCDr4HYOkhcHJejS/d2IaBDLzAXk8L3NPWn9N6JptGNJweziRERdyiMGY56kEdd9xqVJVhh8lIjArJ+YOtTnVwpcC7ab7xsTn2d1ikYQaJ9nL94cslbXSZ ZueXm8vQ zqYnge7kWfw1rsTFEsm8ou6UEv+S1mI/kw2niiXRWjzJRKjjTTu2fhwVKo+S97TT78DpcrYHhVAD77kk/WewM1vTT8eYNhG7LTt/Ldh/2DW+Ek912tjw/a7BlPB6Xc909893oBGLOtpmHkvyc/wmRuCv3y73XJy99AN/+vySb1QEzTcni8ZtEIQuvQ4E6wEWUXfQfgE639nJky8JPB34GSTcEQbWYFN7Hk9Qh12cgtw5PqT+DqnTyre8HKtO6g2gid0C+/eazp4BanJZNj67oTOVH4ABbqRCOY4SISTtzIzRCFjk2qOKEE1HGZVZbGEbHTj6NKdU/DeZ6bKmRJlKEiPGNeQZQYqmqC0CAkr4l3zpx7ZvQciIOK5VHBkUuUZUxNNJTgEudhUm4RkOQ9a6vtiUMAmpzdpywWkGT 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 Thu, Mar 02, 2023 at 09:47:06AM -0800, Chris Li wrote: > 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. The problem with that is that zswap needs to be able to write its cold entries to flash. If zswap and the backing file don't live in a shared swap id space, it means that zswap writeback would have to allocate a new device/offset tuple and update all the page table references. It would impose the complexity of swapoff on every zswap writeout.