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 6AE72C3600C for ; Fri, 4 Apr 2025 01:46:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25FFA6B0012; Thu, 3 Apr 2025 21:46:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20EC66B0023; Thu, 3 Apr 2025 21:46:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D7706B0032; Thu, 3 Apr 2025 21:46:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E50CE6B0012 for ; Thu, 3 Apr 2025 21:46:32 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A8182161420 for ; Fri, 4 Apr 2025 01:46:33 +0000 (UTC) X-FDA: 83294671866.06.D4A0B60 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf29.hostedemail.com (Postfix) with ESMTP id BC052120004 for ; Fri, 4 Apr 2025 01:46:31 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=AsXxM4zf; spf=pass (imf29.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.172 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743731191; 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=BH2aHcExBTMRqIth3acThTGZnzhH8VgR2gO8iFkm1uA=; b=tBYTCUXNm4P9rOFOXlAyNmi0z1GUXM6O4Y9LxtMqjbmFPiSAm1E1QD0idePLaKsH37lePl bchV026UmB6TCXND/cs3ORiCzAe5ABJNyNgirMgENR1CXzNzSK8Xd5pKqbFxPMYnBv/x0W bfILB2tPhggjX5sL4iNAubqren6v1ZI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743731191; a=rsa-sha256; cv=none; b=77h+3vMDUhh/VBdsENeTlczJYsIpuoHJ9mbInAEDciZXxra6Pp+dr+8vx6Y4XgY6Q96G6z bJ8XpKwBjNaW3D8qPVvWSc8u8Sky/N3fhZJadI4KAWTWn2keRyFsnf5PhqNoQ+v8IMlOFa 8Dny5i0T3vht3DRG0cz4qpdJ0ShoDX8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=AsXxM4zf; spf=pass (imf29.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.172 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-736bfa487c3so1289589b3a.1 for ; Thu, 03 Apr 2025 18:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1743731190; x=1744335990; 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=BH2aHcExBTMRqIth3acThTGZnzhH8VgR2gO8iFkm1uA=; b=AsXxM4zfaOJWnO02TEKm0ayIVm4/znixy4X8z2CVleXqg0q7rC4I5UjpXxb/f8yjNu DjLZGpOCfuJ4j+eP/vJ2pxSZVkZq83YEuzpkqmq91mZ7hsQamk44MwZsIXdT8pexbMW9 lzbE23S2IjBCQJkY1jg5kQkEKQQlw6fcg7qMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743731190; x=1744335990; 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=BH2aHcExBTMRqIth3acThTGZnzhH8VgR2gO8iFkm1uA=; b=KNjCT8F21UBQzrmpQyp3k0AWZw0vn2eAH7rTvSFT5tdm4ttREJZq3XV39qgv9TzeH8 xX+g2/5rMRcNnGtESplUsXsPQ+vP0MPYYJ7DFsniaCYpWBExhzawteoQDA7Cz4kPU8BS yPF8BamMwDPjSHi1rperQvIzfbCpvxjioi7MDmGTR8ksZu+ZbhrRdpard8zIu0hNQB+N COg6OyU1NbYwcaurU3defJmhyEEedNcngx5tMwR6HM7PT/idJXBJOtFqgQ767PtLqjXK ISUAiJ27czHHnxCV16WwHpSRVCh9yJdVWSaPg1NqsxDbcLz2W8KIqpPbiooPiqKjMtd0 ibrA== X-Forwarded-Encrypted: i=1; AJvYcCWD+rRfKBkKAN5+Qez8FljMi5TrgUeCJ5MEwk6els4DmrbmRTPAiNwOxGBPWNsg5tlUwxGWxIx8kA==@kvack.org X-Gm-Message-State: AOJu0YwUq9UNU1hV8eXgLfaDK8mdCnCYswZls+2psmQ75eUr94hNJE/C +x0NFDvQyPq/xnyen8QxVz+WEjVoVHAoIthwKh6m8db+eViDOU+2FFigd7MiKw== X-Gm-Gg: ASbGnctmAgjITyj7OhrFecPra+Oi7GoU5JiIo2ReTzRHposhXR6nLY6dmb3/Zz7QlTP vwsJPYyaz4tcCaT8dp5eJqONvJexH1UYrW4DCYB67Y8yZqi1LlIRbfv9a4dShEzK+9vRMMwge1b b0zRFM0/YERvPUiUGAyi8hwmK54ogjrM2vHa1c6dDcrlAeTonzPVpOt7TctbRhdqIlC1E+p/GSu yEOuQ8bdsqYsyG93iVwHb1UfmFbQq+8C2soSHmK+ymG25lE1PnXyD8SSfPM9AEF3l/tOWz3wK0O nEsDDk3+VZrjFA8pPBH1to1pbodMJ/4TjWDA36a224HISljW X-Google-Smtp-Source: AGHT+IE5o5PMSuPfCnveajftPVKH7mApiMqge4MN32MhokwYc3lZTgKDDqHpRmd43thjUiZuif3aDg== X-Received: by 2002:a05:6a00:398d:b0:736:34ca:deee with SMTP id d2e1a72fcca58-739e492f5b6mr2432968b3a.7.1743731190509; Thu, 03 Apr 2025 18:46:30 -0700 (PDT) Received: from google.com ([2401:fa00:8f:203:addc:e770:41f7:fb85]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-739d97f3719sm2199429b3a.71.2025.04.03.18.46.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Apr 2025 18:46:30 -0700 (PDT) Date: Fri, 4 Apr 2025 10:46:22 +0900 From: Sergey Senozhatsky To: Nhat Pham Cc: Joshua Hahn , 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, senozhatsky@chromium.org, 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: <20250402200651.1224617-1-joshua.hahnjy@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BC052120004 X-Stat-Signature: irbfximruqmhtcwnsfsw8sgom8dgf6c9 X-HE-Tag: 1743731191-343442 X-HE-Meta: U2FsdGVkX18SYORXeKdEzz/WIWvpJ1TuA8IIu2OGSgaU9ayR+eH5SFPQwwF7EV1ZfKmpvKpqpO7NfcPQjq8XLN/tcK7//5WMPF83GqZ57tVKI6jzWAPMrsJ7g5EPt5S5i/f35woh+CB4SAf/6BQRLZsc6+sYUy7nK+2YN7qf3sp4sQaycUcvX5Qe3cgFa+pDqTs7/wHacDUE+hMJyP8vTk8g5afyYAx2SN/F1F/Ofv63Ukmp3L00+GH0Mj5pB+udh96e5IXGjs5zf4npo4MW/l6KEp7nAZfXHEpfAasUwVjmjR7BAXvaf3HL9paucAy1mXDLxnFJCd+JS49qhVTv9CYGqe/UZbNNIz9F1BVjxf+bEwXnAXNQCrxZxwR4gHcEkDw3iqpfUBZZ1C7W587Cc0ux1HmOqNBNAq64MKyBis2vNA5FvXBsXA65BTN91oClEfpyJ/+3vUMd3BgcBrnERRlamrMzej/6tzfX4qNiWDee6CisILwuZXCHGFybg/2m1YH8XTpcEMhIwR7UAM5PohESZF+VEBggntE82iA9KLYycY4NQuxImt5DpXydBiPhX79Oz5QSRMiC/caBSkZFCH+LkMYuFZ+IE9IHdVf6d3z7qV0GX2nog/Zaq46p6B6vveMnb3iFMS2MMMP2mT/NsEnzBNHeXp76HeJIOEazPNYzk+g2Xq4D+s/KR9WxB1KJVtXFIB9+WkDRu2uHige8W+8aDIOsXtTBA+XOdI+SapnFWIjow8lXIEVegJTnUY3MSFqjvBL7+H6tgNHxo08t8dLkiM0uOM4A3c0oFJw1gV2TEzJd+L2Pzfeg2s5olRjqhEPE96u15dsSA5ykw+3lvZln/b7eoh57CEnmTRvXJZWVxKhn6/2ezreCrKn8ynuCygscwUW5q7SsT+h9l/z/yhEwDdzuIz3fGAV4cb6xZLjoPNESF2t/ZmrfZdOMpraTsXFmXnYeI0lyp/EQFTc ZxJrrPwD /H2P+pO257dt3Ly/P1EQDjB4c9WCEvA1WLLenmeIQP4uBUHvjH8d2ADW298ZgrRsmYkZ3gOSh6w1EbVvABeb6mLfClJciYAxHxb+foR1pmabq4gUkqjbzNZy4kzDUuMb15Oa/7Qr9YtAj2WnpS36Q28fMQBs62Y6xvfUcrM3GMUjFHa7g1dBZPHEaFR90DQyhYGO56yjRKFQLU+zUd7qJwdYENleQdtuon458rsNQpbDv9FVlUhCdcrOr/a6pOlJvA7Kq7IiglHAbSxwl9HkF4LvSvX/nKKpP8G/YNhmGnyupW7gXtiMVl88YQvVnHnG3/R0PbCyK7JsOOfxDO95iYOXqAvfzW4CQ0DjU6PPuaXduh9sniYXJ6Zh8urDGGHpZW0BeYqHwhpQXGIXCV5zGNZeJjPndbcOSuzv3EnC3YpPiZ70srmsHXSUH7w== 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 (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.