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 57B60C36010 for ; Tue, 8 Apr 2025 03:33:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C90B96B002E; Mon, 7 Apr 2025 23:33:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3F6E6B002F; Mon, 7 Apr 2025 23:33:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB7596B0030; Mon, 7 Apr 2025 23:33:48 -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 8A4966B002E for ; Mon, 7 Apr 2025 23:33:48 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5B48D141C00 for ; Tue, 8 Apr 2025 03:33:48 +0000 (UTC) X-FDA: 83309457336.25.438FA2D Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf24.hostedemail.com (Postfix) with ESMTP id 6B5DE180003 for ; Tue, 8 Apr 2025 03:33:46 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=JPTIy511; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf24.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.171 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744083226; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=OCd2bh1YEOmLh/qb59SX/cgaK+uJYxjcabn/QHo1DhE=; b=MREPHKoejyMa0Hpqo/2e6aRDIm0PRo00qNVjPcQ2bZsz23TilnuyTK/E+8aD6OfodhNMNx mMOLfG0c/KqRSEwhnzou6RmCDk8FpwULM7gyjqK6/5Py6sPrGolwMjc6YL9l5/pyDJ+PZI b1IDNpOrRjqO12Z6s+wTzLn3hulPNaw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744083226; a=rsa-sha256; cv=none; b=Pddktelas+1AF8QFj2iJXWFMuGEuy0jqqbOP8d08OscVF3ZGAiTToy++YcLTEQlt4ujMBx w8DwHyW3fZBBDVksUNIn5vbJZgKO3vYJMnx8NpfI1vYeFny5pha2/3aIlOyRS+1dRlG17S MS0o4jyeuqrLeAMlCX3PfhPnvskbjWs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=JPTIy511; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf24.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.171 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-22580c9ee0aso53939845ad.2 for ; Mon, 07 Apr 2025 20:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1744083225; x=1744688025; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OCd2bh1YEOmLh/qb59SX/cgaK+uJYxjcabn/QHo1DhE=; b=JPTIy5117/z8BA104ImkHR5kEpUtxP5lV6i80y2A6FgEmnNIU3ymnPsUtgPLPQi8Ft NsE/F0Dte6zl5nf68XWSBvjsrz/IEzOcXEMq3zVWxU1hLGciJkxwIHQ4lZZPQ/KRujrh DpL17src8yBMz9l8/cmou8wcrHcAsznEvxFag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744083225; x=1744688025; h=in-reply-to: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=OCd2bh1YEOmLh/qb59SX/cgaK+uJYxjcabn/QHo1DhE=; b=d/i1DKqQiw5A6b8UTzpbBJbh2EqpVusAg7CfA4YPKvHykiLrg0Offa42n+YvF2opQ6 QtbOD8yErhP5YyR+rgqGxh/OIelUOqTyuziN3JAFWWT+YzZzWrQ5aFFCyAnn2ojWzLfA FmmCcl4Pomz7eq6oBGQdEBI4HaMsouXjy1aTQQA2BaeydeyuvUD0pN9BaOuX1JxZSCW+ w4d8Vnr2T2XpHtCxGiaxWJ27fOXsyyJ+p69F2N9UWxwWsUhvRyszVmGDdZ4KnSgakieT wOWACDIO34h1Fse4pLDA0x6S0Q2XAPwD3gUyOji2s5QhjNYDKBpD1/LeAagMvGW7UKAA A5uw== X-Forwarded-Encrypted: i=1; AJvYcCWwqUAx3bx6GlhES8sJkYLxsVrri/PTojFeOxImd8NK8EvETWng352xSdtGEFL2ITiynQQjzOeDiA==@kvack.org X-Gm-Message-State: AOJu0Yyj53WSzAP8yFsFQp/2MhDQUbBvDUTQFSIStJBSEBNRJ3PdEiJt DWmcTzeoGpyFPfAfdgpmFCcyOrvMC468zqW70VFzdNYTNB1e8iGm4N72IxrjEw== X-Gm-Gg: ASbGncuub9c3r6iDhZBqS8kOGSr5lo1ufJKgSMNXZJOUGEUUP3W/rdN9o8zQUaP+Ir6 R4q0XFtIT/6DCcqJCPURUFyPZzqD+T9BusybNM7GmN3uM2heklgEF0hIEi1Q52vQQgCdYmhq7EG N91vT3ZlvYAawyMrYkoO/RB/BOK+RNpgM6kyno7qfO7U/rBhcwOTrULeFU7fliTCUluTbPMn55L BN+akEUVnfEOhlMbblyhCYAp6JXSqcDK7Lt7bp+0h7DN/i9KadfxMfKc82W84KqZrPPEQzzpC/s I/W/PynqW4hiooeupDNM/LR0d1N2c1BfSnB+BGyHjPCBEaY= X-Google-Smtp-Source: AGHT+IGsjihw0vSr30RY1gpqd18IjtRh8jY4OvlAGINJ/64l5H7uM7maXht1zk0/bBCOIGVs716dOA== X-Received: by 2002:a17:903:1ca:b0:223:635d:3e2a with SMTP id d9443c01a7336-22a8a8745ebmr199837975ad.23.1744083225206; Mon, 07 Apr 2025 20:33:45 -0700 (PDT) Received: from google.com ([2401:fa00:8f:203:a4c:d4ee:9034:7421]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-229786608d1sm89620375ad.120.2025.04.07.20.33.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Apr 2025 20:33:44 -0700 (PDT) Date: Tue, 8 Apr 2025 12:33:37 +0900 From: Sergey Senozhatsky To: Joshua Hahn Cc: Sergey Senozhatsky , 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 Message-ID: References: <20250404140628.2049848-1-joshua.hahnjy@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250404140628.2049848-1-joshua.hahnjy@gmail.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6B5DE180003 X-Stat-Signature: d1pbp3fofnibc4bwagfbfb356y4yxrdf X-Rspam-User: X-HE-Tag: 1744083226-190133 X-HE-Meta: U2FsdGVkX18z7LJ9NXCXi7y6mZDXm5oDhVlQmD+5brYs5oU5JCLbPcSywRMhZwA44I8jisSBz6fFDDKN0rgoCWez2dW3aE/BjL4rQmh51ksi7Kz65WbhC4BMKHIuSAbAD1acRtuQ5U4aTQqOVLYeg7pf94i5JSWinUerURawti5oH8UPS42XU+vFaLhOnPzR+eKswMnYP+qvtz+kFDliMCcjqoVhYFo2WaPzzCVKIHaqNIbzcjL81O5Xyq/RN4D7zR7nga6aMVe38sZ3wX3rjwWJpOzTGW8288ecyE9J5lCw9whIP/8qFWiGVlmY2mXeLK2T2EPTZtvoKePjqazZVFl2/JMH/xFDHCIFz8g6QV1QDo78uTmwZz0I1xp0O5rKtIm28eo9SUOH68rkOEcqrxqeXBikjE3sDa3EzeVGNN8L9gqI+ZAj/FHdAvbLrjyTFvrVfwDiWagmVegH0x4lBCCYL30zbw9hLUCvR37nVrMO7ORi0uYpJmmGkM6F/+tjY8KUlmGTrymNOjzGP6M1/rTGINbl51ujbIj+s2u284MKl78YlctMcy9+wCPj0ALjapahHSwnm9hT50YgZE6UWBYcx316NJwThJaSxiKLsJq9Dv84l95X63ZzUr2ldSSj02wRiRBsSCD5Qa7okqHsk/ThMoDlC9x/6bu3WSwbyIJFIJFfGCm4wB7Nxpk9j3Gs1daqlWP/Fufh0rG7jYXnqXGOLLLBega5ydaeGOAzwvcI/gvxHNtomYMLVOONg63xCFIh5MWm/FC4jIgEefq02hz4ZRxWND1bM7Hat7pkYyeHeFqeh8LLlda3jDEdl8lkSDF2ike7lPntUd3OHvT+COvtJ9WL57lS09K7T/Kw5A6MNCtFuZgx4XXUn98zkSUpLRo1nwY/ZdViwUJhowJbZwf2Dq4R5RSo70RuNm4QLy53nlZT7XH4bn/qZxixjOZGOpzRgCVu3ujkljJflqo TRrCsAhO ReVwQ8M3kH6nR8RSmooo6CYTL0Oy64FrfuZUrBuZMPtFmtIe46u1PUiuJXd7aemMvrwHVUdij4Z87qA3AvB2mIITfhNJkp43lwZRvDXSN0iQvdoS5d627EzULFSQXnpd11MF0DGHh9hfwwtzyk7FeAJSYJ4/R62pMFy0/zMvZC9rEUS88o7WT7go1rZ67Me1jJduciZO1dCvYRwXHZWjxONbw8Oh8jchagTbsPrwK2gZz8voS3ozvPFjFIztfhEyuSP6EXJZj+GtE3e3sXxa5GpRXY3HgnOtuCnuiHP2otk8ap/KgsACP/N+J+P2BHQouacLezBeGugXvJVweVxxZamJGZ+FpKMVveiMB2Bd4JWNkDwb5yDJvVGBfCZ3nondjmSIpNLLu5gX5NFB0y1drr4urVFZzr6wgHyVzrDWd2uPCBx4= 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: Hi, Sorry for the delay On (25/04/04 07:06), 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 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. Well, yes, zram doesn't have a freedom to reject writes, to the fs/vfs that would look like a block device error. [..] > On the note of trying a second compression algorithm -- do you know how much > of the initially incompressible pages get compressed later? So I don't recall the exact numbers, but, if I'm not mistaken, in my tests (on chromeos) I think I saw something like 20+% (a little higher than just 20%) success rate (successful re-compression with a secondary algorithm), but like you said this is very data patterns specific. > Thank you again for your response! Have a great day : -) Thanks, you too!