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 B5B92C36010 for ; Fri, 4 Apr 2025 15:29:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55185280003; Fri, 4 Apr 2025 11:29:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50054280001; Fri, 4 Apr 2025 11:29:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C871280003; Fri, 4 Apr 2025 11:29:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1CB0B280001 for ; Fri, 4 Apr 2025 11:29:42 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8DBCA56B28 for ; Fri, 4 Apr 2025 15:29:42 +0000 (UTC) X-FDA: 83296746204.24.776FBCE Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf06.hostedemail.com (Postfix) with ESMTP id B0CDD180007 for ; Fri, 4 Apr 2025 15:29:40 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TIOkpoz6; spf=pass (imf06.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743780580; 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=WZfJaXWQQXLNloYcFnObsdg4J1wfnipetY87c4ZgF5I=; b=62q55G76143qF+fC+MqkCpyaoNDtJQWTMNHjN3OYfgl5ul+lg6oKnasdP97O4Y0o0EvGt8 1Qerx6SGf6CB4WTzLnemgzACqYy/Q/OM0McVlLv/T7RTJ3BbFIGwTKk69e9jpPCarBQgta kw5Dvj9g0V78qrBUhQnXOGKqRDqSNAA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743780580; a=rsa-sha256; cv=none; b=mkTvNaKle/GXGl7HKkHsgQQsAH5Vw2hQFq8kWI8ptoTh/EK66VBkIkvktP+89CBoemkSpQ SbmnkjO0Ll4v/q2s0qo7JhhgkXBf67Jf1WBquBl8bgeHryBgxkGG7pELQRqV53XR5ZDhmA +c9yVX7vP5+D5UMzzKC2Fe01LxL+/gw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TIOkpoz6; spf=pass (imf06.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6e8ffa00555so18829446d6.0 for ; Fri, 04 Apr 2025 08:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743780580; x=1744385380; darn=kvack.org; 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=WZfJaXWQQXLNloYcFnObsdg4J1wfnipetY87c4ZgF5I=; b=TIOkpoz6w6Un+7wBghBW85NdB1mZATCOlxjESRebKNYl/I96XKNQi4Y3c9ZA6bJWR5 IeVsJjjvqYokfc5IrMLfo8Q694SgiAlQZjfDoiHECfCigGmDD2hKuLWj2o93WQUGXybW jxLm5Icds9GDEmtIN4iL/aHELvBMoRLaC1SEp0LmdLyMJ8MuNWGkfFr1Zx+KuGEPhdHY YnmX/8DFSqsTAEbA6ktBrJWpkQP3LYdu78uQ7iqjzNyeChMMNKC5EfUMquYtjUiDp4r2 0SRuxKdhG/vy1JZB6LXKM+/41jrqXmnOZJ/GuqpArjoZkSDGG6yKUgs5RAkt3QhidN04 YOwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743780580; x=1744385380; 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=WZfJaXWQQXLNloYcFnObsdg4J1wfnipetY87c4ZgF5I=; b=hstOmdb/n1Hmgk+7k+Z71J4im+FmDRMVdb8dyy5UfDhpx+EwdTeuOIIVgllvyABUoD 5Phsl8HgRL9VA/7ih5yiZA+yFyRjvNau2V/8CJ70npiemAbn4WGRfZsT7UHKTmZSzLN0 aOz4TvcJN6454L6MWX97opPFlhWENoxGKwXtvU+GNNOJaL6sSEGP5PRAE5HJZmVo+Xuk VSXgxxrVpliZy57p2bxoA7dWw33Pe2LhXRV8rVV7D7UTCgB1TnMMK/IKi4uOmwIkmUVY hStY2KEh35DyI1M3WYUj46ktqfl24yHX9EV1Ds26jThHutSgXq3naGhNky1xx9K3Ysow H08w== X-Forwarded-Encrypted: i=1; AJvYcCXzJTiY/sUV9mVVC6c4eeOIsgYSU6EoVL43+RoKP16VHPRLH85BWhB9MfOXrM6xsb6aZtL610Zw4g==@kvack.org X-Gm-Message-State: AOJu0YxzZR7MenjAEp+o+6N9NcMQAK+KGj6QIJxYxyADom3cdC0MIFNj bgDPR0dr2GZ+jjTZBjM57J9hBzhe9y6SLXkqoHC6Zg35faa9mbrertv9k8gJhcdsftJrd2T1tp8 2SjS3O2A/O013rxakqk3eVNQznXA= X-Gm-Gg: ASbGncsHUcuiRY4FY+Jt9wt/so9xCwckU4QVvyXWY2xFzTf2OXMI7uX13QGf1kKn3UQ V4zGtRLcGd++jIMTRw9OPNFYv0BblWJTxlWXAgdgeLhmwQuuDTvYRL+lwShN80OfmevB++eLku9 FCVHrkxLPp0NQFZwxZWwEpZY3uO+fEsf+9A76wdE2DMUJv0SCZF1POq+UoeQ== X-Google-Smtp-Source: AGHT+IHm7lyN0qi+1Nq0kz6GHTRjqT3eaA9a9CZ6vohCvgLExH0hf+Pe4PcXLc55uC7qXOyI+eE79CdP+mApgb81nSk= X-Received: by 2002:ad4:5ce8:0:b0:6e8:fec9:87ff with SMTP id 6a1803df08f44-6f01e7591b2mr62974286d6.23.1743780579696; Fri, 04 Apr 2025 08:29:39 -0700 (PDT) MIME-Version: 1.0 References: <20250404140628.2049848-1-joshua.hahnjy@gmail.com> In-Reply-To: <20250404140628.2049848-1-joshua.hahnjy@gmail.com> From: Nhat Pham Date: Fri, 4 Apr 2025 08:29:28 -0700 X-Gm-Features: ATxdqUF83msa2ZHsH4C_adG3eFx7pC1hThgSJmpRBY5ApU5tqZZhLnneYHkWGYM Message-ID: Subject: Re: [PATCH 0/2] minimize swapping on zswap store failure To: Joshua Hahn Cc: Sergey Senozhatsky , Yosry Ahmed , akpm@linux-foundation.org, hannes@cmpxchg.org, cerasuolodomenico@gmail.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, hughd@google.com, corbet@lwn.net, konrad.wilk@oracle.com, rppt@kernel.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, david@ixit.cz, Minchan Kim , Shakeel Butt , Chengming Zhou , Kairui Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B0CDD180007 X-Stat-Signature: nh41rsnpydxpgz1xfz7psu9ew81jyyt4 X-HE-Tag: 1743780580-889727 X-HE-Meta: U2FsdGVkX1/5yTzKRlUuBtnPI24AIplgVLTJVzwhrG/LEvcwhnq0cPdR6O77K0zokEi8/uu5H0yNrLOD7I91g1Rf+Q+pwSbW5oFHWywiGadY85LRKadqRQHWAFLJsmje2AwJRE3mLUjwVvBqJhziPCBBKZwsUdtkZAjOSxsfT6cYHBcp8qH+9windjYkfAJuVOjxrWj9DuSpnFEBYoqAWB3ZDC2CPJCiIxPnvtTHcU1BDHk5yIoGegTXg6dXl6UpSwopI38qgFSJ5l+hoVdke7q+gCxooYoNyHT8xxYn5xSDHvsYh7GFWuVO7Mm+ZUyPg7qiuPPzmiM0lP2pgY0OqI9f8bZkYDvUyfSe4nr81IH2msaAr4bbZ882VvQDdanJS86zMkH3sPYsiVZv4+jDL/rOOYAYK30UOdw65r7giD8dHh8d87p60uh8ByBUAaFi4kfs/juG/2qNyx6G4C9EEsFtWJPJJ1rDkQhom4ta8rWOa4tWKVB6I947P4W+GCIUHwNrvzYyVW0TNtilpQeH/oXXn1IJscHr69EbDa6TGeZn8IlaxDakA31IlX0MFDglpQxSwven3H2+04LsKJ4Bmy7PE20erF9f2kkcmIZSjbDC38kENcY+9MFq2gExEAER7da6BuHV6N/34K0BbO6nShHi1Yvf5gtporOS4ROyiQujiv7AXIrVnHsqdTZVIZZ/PrF6iwwVcyNmkkNYhaCixXvTi1Mz2RjY7u5IR1d7HvWTw8xrBcozP+X9SfLPFJLh4WpmaWHtBXWSqWT8UpYNQfBC4CAYhZ4KEBn+hyYjoJDpOV/3iPXs4ItzGxafeuXsdFJAFIv8Bw8mztueJiW0re4metewkcijYrICW/fSB3eyBhqW6kJhtrV44+6EZcLaWLm3NsPCYSXGHuo1VAx9S4U/2vl4iji4B+9DxUX+yocYVRQMtRluSQipFD8o3e1TrM/Z9nKCYVSo0CHpt4y r+SXF8IF zmL2jtiSLWlWw3F/wtp9MbSK763ShNiF89KJ7tFmxxQ8we81d/lP3T8Q3GEvlLlqgFJi9TKjMmsvOo3Ez/+e6pCPzRJ7L1KvWrp2ZIBfE5BbFLLRQBMzh2id/FkTc9uXwqslIjilm/RlY7XyTNherUBPGAhHJcpWsEKcOl2bqfAHjZDmHWLaunU2qeUNyEZTrLIfj6dWyxEl1rdKHEFb3QjJlws2z0LncN3eLDp2iOOp/9xfy6HA9GzwnU2recfzB7j5jBo9wMqsr8LCM1oJDlz1T/PMKl6sVm5McxmHEQBb9n+USyuGytNbrrAJJd3mFAI0uhGvbvXx/eyL+NttfXeo+mTlvVb/821QQZJa4b069RF/xBn0avJkBcasfcjbOdACB05tgJ6VfnWrMdAweB27qH2VizWt7TrLu7jztgxdBVOXWUYQHU4wSG0+a1fU2bZH1LeheVEJ4AevrRiwor26SmQ== 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: List-Subscribe: List-Unsubscribe: On Fri, Apr 4, 2025 at 7:06=E2=80=AFAM Joshua Hahn wrote: > > On Fri, 4 Apr 2025 10:46:22 +0900 Sergey Senozhatsky wrote: > > > On (25/04/03 13:38), Nhat Pham wrote: > > > > Ultimately the goal is to prevent an incompressible page from hoard= ing the > > > > compression algorithm on multiple reclaim attempts, but if we are s= pending > > > > more time by allocating new pages... maybe this isn't the correct a= pproach :( > > > > > > Hmmm, IIUC this problem also exists with zram, since zram allocates a > > > PAGE_SIZE sized buffer to hold the original page's content. I will > > > note though that zram seems to favor these kinds of pages for > > > writeback :) Maybe this is why...? > > > > zram is a generic block device, it must store whatever comes in, > > compressible or incompressible. E.g. when we have, say, ext4 > > running atop of the zram device we cannot reject page stores. > > > > And you are right, when we use zram for swap, there is some benefit > > in storing incompressible pages. First, those pages are candidates > > for zram writeback, which achieves the goal of removing the page from > > RAM after all, we give up on the incompressible page reclamation with > > "return it back to LRU" approach. Second, on some zram setups we do > > re-compression (with a slower and more efficient algorithm) and in > > certain number of cases what is incompressible with the primary (fast) > > algorithm is compressible with the secondary algorithm. > > Hello Sergey, > > Thank you for your insight, I did not know this is how zram handled > incompressible pages. In the case of this prototype, I expected to see th= e most > gains from storing incompressible pages in the zswap LRU when writeback w= as > disabled (if writeback is enabled, then we expect to see less differences= with > just writing the page back). > > On the note of trying a second compression algorithm -- do you know how m= uch > of the initially incompressible pages get compressed later? I can certain= ly > imagine that trying different compression algorithms makes a difference, = I am > wondering if zswap should attempt this as well, or if it is not worth spe= nding > even more CPU trying to re-comprses the page. It wouldn't help us :) The algorithm we use, zstd, is usually already the slow algorithm in this context. We can try higher levels of zstd, but there are always data that are simply incompressible - think random values, or memory already compressed by userspace. Yeah we can target them for writeback to swap in zswap as well. It wouldn't help your (micro)benchmark though, because IIRC you don't do writeback and/or do not writeback before it is faulted back in :) > > Thank you again for your response! Have a great day : -) > Joshua > > Sent using hkml (https://github.com/sjp38/hackermail) >