Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp2941782iob; Fri, 6 May 2022 13:58:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPqnQQpzgstZtfBUgbHOKmoDBuN6uKHdLSVmRKtRxEnrBdfY7vcxYfrWyYGy3S9EIfwA/y X-Received: by 2002:aa7:c6d0:0:b0:425:e9f3:10a8 with SMTP id b16-20020aa7c6d0000000b00425e9f310a8mr5520021eds.41.1651870718488; Fri, 06 May 2022 13:58:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651870718; cv=none; d=google.com; s=arc-20160816; b=qDBUSeu2rMuaagLEyfQI8swzNrLH3fMnAkaSK1LkUKPY1fOLBrcRwc4C+qYUd9byjp YSjtWZ4BmhWDqSNy2vS81PrOMhFQA/HkMnsaFQuha6QocjsKbqWM2LnArHto4hY8Pj16 pgpTNoJA+1qqGWiV3vXiOUn/f8P0kHHZ5BFKi7fcM1zy4WNl2RLu3ZB8TualhXIoRu0i ySnX3t8LfPY4jm42cMf34U+Oxg9D1bAiiGTRde/zOG+FZJ1u4aRAun03d3wyffvICUX+ SbGKnebIdNVMQhrJNBWGoXBSl4/+1f71TAreedprdOc0C3NHDD2cbE6M4cQkHKglTvtZ 88dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=gLvYPio/y1Rsy8ZWzpMgmaTLG4G8yUQ5M+BgkCxtwtA=; b=hqf+xteZhtzLzJxkfPSMD2fnvHGov9McREBDViboeRgVV5wHUCGjs56CsO9b7QtnN7 p3omXeeuk8cb2ncwv3w2yxOmFV6Xc9VGBa0u/4EUzGX/D2ZLJQ/iNOrFJqeREME396Al GFMHvYp2z/rFL1w4sgbSQzc5rJmZNnt2cKen1dNOzobAPFCeSVp8JKI/qzReyzD7FNO9 FrnpMvKTXf/t9zOMHA1y5VemjfynKqeGWbAr83v0RiC4G8GBlGFou2YYhDyLpkCyE8t+ Dyd/y+aPgFJrSEX/34vag5a99s/7YU7X/mStKgst4X0mJSn/eTySRQ5QpfPAtPOCjzV5 3Ckg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=XQIzSd9n; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f4-20020aa7d844000000b0041d76d48108si4650780eds.229.2022.05.06.13.58.12; Fri, 06 May 2022 13:58:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=XQIzSd9n; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1385019AbiEETeX (ORCPT + 99 others); Thu, 5 May 2022 15:34:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351650AbiEETeV (ORCPT ); Thu, 5 May 2022 15:34:21 -0400 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7D6F5A178 for ; Thu, 5 May 2022 12:30:40 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id n8so5339158plh.1 for ; Thu, 05 May 2022 12:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gLvYPio/y1Rsy8ZWzpMgmaTLG4G8yUQ5M+BgkCxtwtA=; b=XQIzSd9nao1kbun84GbUFcH2P6yyzDFG+N0A2uCHmVBYC8oODM70pXR7xtStMpfyc5 mtLLHkk0xuZbqCU7Z5wfpn1V3VrJczJhfpGwyYX1NsIjuxhnx3cpVEjvnU072DQm7TsC gFykdkxKL30lcwxhTxXlO00viowVHb31o4Z2Loba1USEpkQpfNxxSXoUolf1lg7eK28D gU4oWX58uS9Uc4wMyy34HH3NIIDZng79hu94xSbuNXAA5Q+YGYbWkVR7CXkiOn3GfgBN 5WSfh48VFtwZ0Z7T/OV4fH9LnOoWTy+y8fK8buNSTDzi/szVTBJSmmRLPwFRFH2lKvwh WMhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gLvYPio/y1Rsy8ZWzpMgmaTLG4G8yUQ5M+BgkCxtwtA=; b=gYI0dlKMrzv5zYtBefgxBhZFJPMBEav0F/JdKAFOylliqZDxHE6FAbeztEuNwPM8Gl ElOdBzwjqY91Z4pDzPUqW2AFsEJHQEOU4zxL22lb8GsrX/Jz+VnbSwJK7FnTLz0LFfH9 RGTMJjH0cyRBOX0LXyOYBq4zfCVRy+nXdJbncrNiA30iGpRQoNUToYfQC78F9sH7xb2Z wBTpUWsFIJsEH4fPIQBkYKY4FOgwQ2ZncJh74fkZnONR7F5nip4rdP0ILKdLzknlk/3r hARTRm0O664WSG9VO2NPa49F3I0hQf61twFihBqZssMBSperJE8s3tenjZu3jpicI+A6 twbw== X-Gm-Message-State: AOAM531IxgpzZVRYcU3SC9fEfeV9QXWin7GG4igbYx8B2GI7zvujcXzE yFPlUT/641/vfZ1NMEN41q1lcgXoKzyGIEUtIUY2uA== X-Received: by 2002:a17:902:f682:b0:15e:951b:8091 with SMTP id l2-20020a170902f68200b0015e951b8091mr25548653plg.106.1651779040120; Thu, 05 May 2022 12:30:40 -0700 (PDT) MIME-Version: 1.0 References: <20220427160016.144237-1-hannes@cmpxchg.org> <20220427160016.144237-5-hannes@cmpxchg.org> In-Reply-To: From: Shakeel Butt Date: Thu, 5 May 2022 12:30:29 -0700 Message-ID: Subject: Re: [PATCH 4/5] mm: zswap: add basic meminfo and vmstat coverage To: Johannes Weiner , Yosry Ahmed , Yuanchu Xie Cc: Minchan Kim , Andrew Morton , Michal Hocko , Roman Gushchin , Seth Jennings , Dan Streetman , Linux MM , Cgroups , LKML , Kernel Team Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +Yosry & Yuanchu On Thu, Apr 28, 2022 at 8:17 AM Johannes Weiner wrote: > [...] > > > > Yes, we have some modifications to zswap to make it work without any > > backing real swap. > > Not sure if you can share them, but I would be interested in those > changes. We have real backing swap, but because of the way swap > entries are allocated, pages stored in zswap will consume physical > disk slots. So on top of regular swap, you need to provision disk > space for zswap as well, which is unfortunate. > > What could be useful is a separate swap entry address space that maps > zswap slots and disk slots alike. This would fix the above problem. It > would have the added benefit of making swapoff much simpler and faster > too, as it doesn't need to chase down page tables to free disk slots. > I think we can share the code. Adding Yosry & Yuanchu who are currently maintaining that piece of code. Though that code might not be in an upstreamable state. At the high level, it introduces a new type of swap (SWP_GHOST) which underlying is a truncated file, so no real disk space is needed. The zswap always accepts the page, so the kernel never tries to go to the underlying swapfile (reality is a bit more complicated due to the presence of incompressible memory and no real disk present on the system).