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 C6B8FC7EE24 for ; Tue, 30 May 2023 21:20:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A6BF6B0078; Tue, 30 May 2023 17:20:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4565F6B007B; Tue, 30 May 2023 17:20:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31EC8280001; Tue, 30 May 2023 17:20:42 -0400 (EDT) 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 1E8776B0078 for ; Tue, 30 May 2023 17:20:42 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C87544035D for ; Tue, 30 May 2023 21:20:41 +0000 (UTC) X-FDA: 80848190682.18.4642BB2 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf23.hostedemail.com (Postfix) with ESMTP id E9B4714001F for ; Tue, 30 May 2023 21:20:39 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=OLK4N2ZV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685481640; 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=jMgiLGfQY4K8q8It6kJThVSmE1j01dNv8Q5A098cJZg=; b=KvtcdMsr6tOuJXIk1M0YOAHeUPZQQ5yl5ALLS+sZTxUqNtOwZtMkBHC0B/Og0utrrqbDPD cjgKcRvXaPJQDXSMTGz11W1tuvT4O5CQz3OBXJ0ONdSOy+mzpGuu/ejf3CZWvzr36EW0aZ Rl33E7UEaFu7YDy2j7R/4M8aFNmqmrA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=OLK4N2ZV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685481640; a=rsa-sha256; cv=none; b=DbWB3Z5Iz0GMpKEARlkXoMEPbmoBGUPPTBjYiXYNfH1ZYVzi2bUI3cjRfVeoBIBDeNBcIK Qtu9Q9wmIYW+oRYUHqVy2haoE7xKyyYRD6S06lnMaOdfzYAZ8wuKNepHTAA7+BS40rWzQP 3jwC0pNmjTwlD9oTPXcaB4mtwt96IhM= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-96ff9c0a103so718784766b.0 for ; Tue, 30 May 2023 14:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685481638; x=1688073638; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jMgiLGfQY4K8q8It6kJThVSmE1j01dNv8Q5A098cJZg=; b=OLK4N2ZVIECTEdD542qtMV4UeyeOcMLKuxHtrmbJLAN09hdUPkJjgO/Om1wh+36n78 reU0DbmtM0Skg20UOwEKxmrMHMGhw3M4Qj1jbiuzaJUGhAmpkzaRLaFgl4MCOB5h7Ltu CNOcR0i+gkVIiSX2mZ3zxTP6yVS7OTi77hTo1nxYTzvXKBFXpTed7QXmVqbh9ZkAp2+q 5mw18/wxpdL7ZiZydH/hY4WCD78hUg67Qm1PwaaGEkkBsM04p8NNpt8QAmtdZxKrxJW1 5BSTIbAR9Fj7sJkcEWTqhWSRtjhBFI3vUCostXcEa2ZrsFBZJ5KZcbc9nYgl2hvFgxRX 29UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685481638; x=1688073638; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jMgiLGfQY4K8q8It6kJThVSmE1j01dNv8Q5A098cJZg=; b=YaNwugstTonH6s3AVwwfKWkr0GnNQkcKra0R3PoBM0iBre1CX72+r0nHWzi4Cj/XKM wG6nJ35GBkkNtdb/GDoCBoEradYBcenrfTYlj+ERwRcBFWiKdSuXkcPfKKU2di6hkMLj WXOOqUhtVc7mamHdQg4rv8XYjD+bnXvJvOxnhTG4d9Bu+TOWp0v3VwG6DVLAYcNZp3bJ yO6rQ96RCFhuKchkBqnBLKUIGuDd6vfNxtx/l9/PPPRuQmKaEfzWxNHRhq/OwVjvxg9q q0uAQr+58MxOpXLv3LJxybMJX/7+HcbSmJCeZpQGmyZXl5PltwWsIRcpzGTumAZd+80w bWYQ== X-Gm-Message-State: AC+VfDw+0+M0VBf788pZj4co/F+eZHHm89BFI6CStcF0SmVgzciLGcHC ilpuqdSN69A4op3wLdnyyWCdlsO74g6aOdvReXMZHw== X-Google-Smtp-Source: ACHHUZ67GOY7kKYCgiNWjTC19+TLUBNL/QCaivt1MXil5qIddaAYtxcvL4i/gEoXq+hYlFCPot6GKoKeYdwedhr6d0I= X-Received: by 2002:a17:907:9813:b0:965:6cb9:b768 with SMTP id ji19-20020a170907981300b009656cb9b768mr2770998ejc.31.1685481638228; Tue, 30 May 2023 14:20:38 -0700 (PDT) MIME-Version: 1.0 References: <20230530210251.493194-1-yosryahmed@google.com> <20230530141547.609c4a434470c3fbf7570ff8@linux-foundation.org> In-Reply-To: <20230530141547.609c4a434470c3fbf7570ff8@linux-foundation.org> From: Yosry Ahmed Date: Tue, 30 May 2023 14:20:01 -0700 Message-ID: Subject: Re: [PATCH] mm: zswap: support exclusive loads To: Andrew Morton Cc: Konrad Rzeszutek Wilk , Seth Jennings , Dan Streetman , Vitaly Wool , Johannes Weiner , Nhat Pham , Domenico Cerasuolo , Yu Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E9B4714001F X-Stat-Signature: zq769o3oikzxc5y9gogiu8wbakdtngnd X-HE-Tag: 1685481639-867168 X-HE-Meta: U2FsdGVkX186iMbZIWGx/pUwzFmLa9TKhaZI9xgiOUEwcF3xPyXS3hUV5x0FU3vKg63kuVmB5XWlwNYiircIa2LVgdwMNUEFpEgC1Rb//s0MzdPkthOmxEBxipoXYOt7ek/EQILKEuRixK794PQrel0YnSv0KqLwzJAyU6R0VZIcjnt2f5fuO9sntJrqt7mOworegb540mJjpt7spRdWE98rZsmvLzYdQmEDFF6w3QhQ3LxRsl9mnpY2FIDck4QaJvaTWQvfh2cCxJVBd8FlH7lllYUHKDhLPflF1WDhqxN3ZbKZ8LFY4hqAlxkKAphPAkjpd8xkYV6RRS+VZ1eUZBuryzka3rEOryD/sEX3DijujAkR3fPSdKU8pEgo8nxR2ngO5j5tbWRrgH5aZXuKnR0eVLJsRjnOGA9FmuNLSxP7cj/kIrK3mPkyaE0qAljqdxOfGFmQw7vp+0wTLoNIKNoH9ho0PCBkmTqGoG3q0JTbeCd6J8mC4C5mpTXURSvOpu/icqpKCbnNe8MFFdoNirx8Io4y5yvg8nZmwKyGLatA95FsALQC74luLGSShaDDTZWJRpO6V0+SbRB4Mk9ARmUsNq0/0CuEwRIZbgIFjHBYAwKKsD4Lkx+6AdkP6Z+jTrqzcelvGxQF6yF07qwKAmSuB6fo+TaKop6aAATovY2zgb+ceEz0jn1ZYrrCecZCMMxYjbIe4+nf8zBHU/q+K+gqt+SI7pXAoAxP0k3UDpvkutfBsGpa06SuO/cNRF5e/r++hoG7cw7CeTUEjN+LBfEs6HHPr821Nh2OyhmyQrEq1H1LnbMOzn7fnie4gJj21kRz1bl1BeoOoEkWcMt4pgTPeq1B1bl95hCp//AB/VENd3RZGSMvshRsE/piMIgIW4liyvn6cgfPgsbUna4Pzjovdwx96JWsAOXw79QLAKrrQmxmILWWDwAv8jgVJrG1p0N0uHKepF+UCBbNk+Z BLWIQzHD 9QAO/9OiNXcdxzS6ihXZEeXxWgp2ZA/zPEJLtaB5JBK81unBeIjbhht9xPFD6xpI+pto0t8a5eusWwck4A98q/S9j2tcjHUpmwUt1ObN6BChQ2FzqY58DgTP2NTtpeenZGAYTaKy7VqjzIVmD8Fo/wbZQhtQaotPT9btnQvMlL2lyZtHaQ+iZo05VZCEMdkIsaq8Hd7pnoOE6YDC3LmuZ7nGzJcMpmUaG7ZhcCpFFl+3aiJn3Oz1atSxG/faw02xK5OgNOHJVzPZUUGjzasKixV+6VtoXz7+KcGTed9PAAp1GwMpkeF6RDr/zq6Fc8brxeQJo4WAZjChqANbadSr9c5yPD9f1Nro3PS3xrgY4+bAwVSY= 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 Tue, May 30, 2023 at 2:15=E2=80=AFPM Andrew Morton wrote: > > On Tue, 30 May 2023 21:02:51 +0000 Yosry Ahmed wr= ote: > > > Commit 71024cb4a0bf ("frontswap: remove frontswap_tmem_exclusive_gets") > > removed support for exclusive loads from frontswap as it was not used. > > > > Bring back exclusive loads support to frontswap by adding an > > exclusive_loads argument to frontswap_ops. Add support for exclusive > > loads to zswap behind CONFIG_ZSWAP_EXCLUSIVE_LOADS. > > Why is this Kconfigurable? Why not just enable the feature for all > builds? I assumed that some users want the current behavior, where reclaiming clean pages that were once in zswap would be faster. If no one cares, I can remove the config option and have it always on. > > > Refactor zswap entry invalidation in zswap_frontswap_invalidate_page() > > into zswap_invalidate_entry() to reuse it in zswap_frontswap_load(). > > > > With exclusive loads, we avoid having two copies of the same page in > > memory (compressed & uncompressed) after faulting it in from zswap. On > > the other hand, if the page is to be reclaimed again without being > > dirtied, it will be re-compressed. Compression is not usually slow, and > > a page that was just faulted in is less likely to be reclaimed again > > soon. > > > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -46,6 +46,19 @@ config ZSWAP_DEFAULT_ON > > The selection made here can be overridden by using the kernel > > command line 'zswap.enabled=3D' option. > > > > +config ZSWAP_EXCLUSIVE_LOADS > > + bool "Invalidate zswap entries when pages are loaded" > > + depends on ZSWAP > > + help > > + If selected, when a page is loaded from zswap, the zswap entry = is > > + invalidated at once, as opposed to leaving it in zswap until th= e > > + swap entry is freed. > > + > > + This avoids having two copies of the same page in memory > > + (compressed and uncompressed) after faulting in a page from zsw= ap. > > + The cost is that if the page was never dirtied and needs to be > > + swapped out again, it will be re-compressed. > > So it's a speed-vs-space tradeoff? I'm not sure how users are to > decide whether they want this. Did we help them as much as possible? Yes, it is a reclaim speed vs. space tradeoff. My intuition is that it should be more useful to have this enabled, as the memory savings should be more important than having reclaim be a little bit faster in some specific situations. We can make the configuration on by default if others agree. I would imagine users would turn this configuration on and observe memory usage of zswap vs. reclaim speed, and decide based on the numbers. > >