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 AD160C36010 for ; Fri, 4 Apr 2025 14:06:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6DF06B000C; Fri, 4 Apr 2025 10:06:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C1CD46B000E; Fri, 4 Apr 2025 10:06:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABE846B0010; Fri, 4 Apr 2025 10:06:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 922D76B000C for ; Fri, 4 Apr 2025 10:06:32 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A34EB552C1 for ; Fri, 4 Apr 2025 14:06:33 +0000 (UTC) X-FDA: 83296536666.21.9743EAE Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by imf11.hostedemail.com (Postfix) with ESMTP id B55B340006 for ; Fri, 4 Apr 2025 14:06:31 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hsSrxVRR; spf=pass (imf11.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=joshua.hahnjy@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=1743775591; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WVPeT41m1KuMRdsIoLoOHCLOtV0jlGQpXGJq8x0yjEE=; b=bN4v1/85ILO/1QtF164zZCVz//FZpSEhY7T3wb9WJ9HAz4AI6i1ue2xHUQId2bTL21bvui c4+4h22tmRGzjFgEajaOZkgkfoPMJ9gvE1ANDGxNRWt1fIs+zsFcDXatDY7XTld4v7jLxD Ny6rBEikQtEw5kj/vG9p2AM1MEodrlQ= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hsSrxVRR; spf=pass (imf11.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743775591; a=rsa-sha256; cv=none; b=W6pAVyaiJdsBN/m0WQIaYu5Q/khJX0+9VJJv8xn09aCQXiH/6qvTWomYkxF2S7tg0PGDWR LxpkeJFADkSQcjR8P9WG3Wt/YOo/PnG9Ap0+eOY7zQn8tg4PkFFq3+tAQ6CH+vl5zLHcBV XOM5t9NEXfazwLq0ZMBi/OoZi/j6VkU= Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-6fece18b3c8so18798507b3.3 for ; Fri, 04 Apr 2025 07:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743775591; x=1744380391; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=WVPeT41m1KuMRdsIoLoOHCLOtV0jlGQpXGJq8x0yjEE=; b=hsSrxVRReJ7UzdTCQmPpPxyHWiMp+iLBcS0HVT8pSmHsJ5QM9bHM1enrroz9mkGBso tYjcBF6q59TVM7nRO/O7JzRbjDqZUNm6RNxoloHT8PgHGeYsL1UgZduKlUNuNfZmBkKx EdiiE5GcoUbylnIoGlIpTEpDGSwUnVigEwWRWpLvvayhK1rkTezrhguPO8Cx1IJFIOS8 y1+aL3mOZcWPQ7MKTw7xvggi7ByQyOr3n+XgA/pHFM8PT8V4onobgaYqnl6+JgILzT0M LpH3cNfz12s/pGXlvM6X95Qp2pZRrFyDUFJI3nukFbbBWISN3+q4zak6sQlYxzJgVQLy 4c2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743775591; x=1744380391; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WVPeT41m1KuMRdsIoLoOHCLOtV0jlGQpXGJq8x0yjEE=; b=l4GbfYXQ8eC0jblvN/pv6I0/uQNivK6EsgaFYNF9deRROGemGo4wc9LhbV3odvsrc2 KpICX7g9T06UH/hR0H8DLH+fB81ywpt8YPa/x0F1Gg7NiDXk6tK3IMKO2YyTk/IQkM5m SUR/AT5JjWAqUS0f/rp60XSD5eVP4oRCf6BOlVQx+IqT6q744U9hicbEUPDlCym4RwQP IQj92ggwojzLrfSxlYyMsdjZ+kQhhIe4jyqoqptymVPHiO/PlXmGHOOIZWDaLO+MaKpq dgYnnEworNGmkuZMTgzNs92f0Ccem/Sbt0GqBhYUOVyWkbSajDBP1+2UY8b8das9BtIF Nr/A== X-Forwarded-Encrypted: i=1; AJvYcCU8dJr8cOxneYFva3RlwDbkw9QWNedYNfBAmWLm56FZMtF0tzGymAA/EZrJnj3CkDqYW9ZYvKfcug==@kvack.org X-Gm-Message-State: AOJu0YzOnqgkNlEkjfc2FJzaN4pmiBrITBTQG1MKMYq0vG4zWqI+94mT qCSVZpRLCuieGDwrGGnA2dTbVkkD7urZYd+EwUCviFVRwbGgQWve X-Gm-Gg: ASbGncteU724l5ME56uTTK31rbyRNUFVet4zP6xz40+Ze8U8KzIw+ioT98OOrDikNz7 KfgpGDSBarK8edthe52jYtpXh9jHBtB+kmeEWuU4XoBSG9h2D6nPlvrPJxphZb4VBLbNoT5pPEe koMzCi09zSunkpMLnE0YWm3IzjRFvBrIvdmpjmeKibP+kglMrgwkhGcfrnX9bg/a/IhuiF1dv0Q 4NQ7dUJzuKf23lec1/eTc0hdeR0SDQ5A9+lEBWKpRncA+LzVK3+KsMGcg1jIrMRL0FiOgWkYWY+ Hcsk1ZsfIWhcplaczSFBDhXkYnwFcKOll4y4M3O3N64= X-Google-Smtp-Source: AGHT+IFTPK6rSJQPLB/U5XR9Q42/3BNUrnaUbEW+Xhyn205mNhyBTj0MML9/4VQC2BCXkVKGjmoR4g== X-Received: by 2002:a05:690c:6a02:b0:6fe:c040:8eda with SMTP id 00721157ae682-703e3108a3cmr44544107b3.4.1743775590442; Fri, 04 Apr 2025 07:06:30 -0700 (PDT) Received: from localhost ([2a03:2880:25ff:8::]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e6e0c8b7c95sm819927276.12.2025.04.04.07.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 07:06:29 -0700 (PDT) From: Joshua Hahn To: Sergey Senozhatsky Cc: Nhat Pham , 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 Subject: Re: [PATCH 0/2] minimize swapping on zswap store failure Date: Fri, 4 Apr 2025 07:06:27 -0700 Message-ID: <20250404140628.2049848-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: B55B340006 X-Stat-Signature: fhw88a5rx5c79cau4feqwjrf5w74y9ot X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1743775591-976006 X-HE-Meta: U2FsdGVkX1+JKFWOZszvNgeoCp0uUkfws8GLjTkBRF0wVd/lpfK2YYhEoddnXHkATbfIlZqFde3POBTiFgmedJrK3Lw6i7QGWYD37pZwSgyOugqzvq90a6cOneRZe8Fetii++Y2rtO9pzC3TtnYB54VVwE8FNXZIYQ5ct6ZgTlml/AufflKz3zc5qf3ea+cfkM4WRDPY1olamEtOsFCywgkIPAFihtZ9h6AqtRiu6AAK1uf5EUGkmqfzLGineWkaacnOXJzRAkM741wWd//pNh7QUVZ3vT0Q7IdfNFmsNNacjUrVm+oHoJBwKJ4zrFBhAV708UaeSmp7zX5m8GoP2b+cYpxac/nFR473tJ4Qy+2P/b7bsUQpdwYLLZleJT3Bmi/SF+67K1U9oAM2LCXFVxIHr7teRYGSscmY2BHJIeP1o/P8QwKhB0zwHxPDZBGSd1eit8xtnQMjF3TpmaduqXaOhn7QvDgGq9WwDRxDJJ0hoZ7xuelaJ39CVorSu0rWGayaeUf8pc1LlyF1AKB0pNUSdItLVIM0fMUytFP8bhqBxYqAImlzXiIiLJ9fnLhBmXNmpW9yB1DqHLpkBzzxgR3gks2Fgj5AnV6JuZAcbgHBrHGmxLjqZxnx29FQLYepyAXjj5KeYBoUNpQXZz9rc/a9QzYiyak6Gvy+z5im+rldnHdUfXlIyrqkW7mWTMfE8IvwS8AF++A65IArGTFyn7/JBXcE4GThv7MQ72kLUfCChjpHJJ73VtPGns0oHoWwWwPlyciR9ZtaaF6lecIBxbwjCzXs4hleZAzAqs10TJdwIoV3ZX7ekPZ6xZE/izSx5YIeJdLF22Rsw0YHnhLvdh6gwGDm0i9ZGKlxnjrjve2Ub7amjCtTmPsV/dT081ceI7vTvS8+2b6Rm6hP9b4LC8uAF+e9HAQVtqWUaMzuxPdjp956RFrtSVXg8kHIWLzLuonUgqwuN1wjcvb9mgg n6Pbo1cu FiKLTgIFqenIoA4dDBaAuwrgJc8KJc/gK82F4I/n8q7Pto4phBVUX20wdqCILDvBzO25SY1MRMe+kBwSTt3US86Ke3zDf6WuISBY4jiQr3eO4tyVJfVC5mxcIzlzHDkD+NejTUFohpbHukixqd1/IVCytP5PS3vedo6iTj+LXY2IzPh+PqT5fowiB/50dmixMP7nDCYO7ktBWq5eEArwmUZSN4J3DjL8gHSgfpvLhlDJweMznPQk7nRWRFEWsPxQBZV5bs5FZyiTxkWlpIP0X3ExUFDSeDiJ9e75Tx6gWHdsnr5NT6c4iZaMagbRlZEC00AkmIFXJthgLqm5rLIhBD2xGfDw7oc9KY7g2w8nLoKPYu5o5OcIOUTGflSnzHkOp5UX5tFuZ6ko90+bSZGPumg7dxZP6HTMox/HurQ6LcLS+UrVn7CVzqH2q9hv0JwprAqkjj12rvYvQpsBR26n9V8DxyzqxOniob4lwk58DRzbjCk0KbRsNz5pz/+5hBKoCDPUgbOQzl8xctZQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, 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, 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 hoarding the > > > compression algorithm on multiple reclaim attempts, but if we are spending > > > more time by allocating new pages... maybe this isn't the correct approach :( > > > > 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 the most gains from storing incompressible pages in the zswap LRU when writeback was 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 much of the initially incompressible pages get compressed later? I can certainly 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 spending even more CPU trying to re-comprses the page. Thank you again for your response! Have a great day : -) Joshua Sent using hkml (https://github.com/sjp38/hackermail)