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 CBECFC30653 for ; Sun, 7 Jul 2024 09:38:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C5B66B0083; Sun, 7 Jul 2024 05:38:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 175D86B0088; Sun, 7 Jul 2024 05:38:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03C8D6B0089; Sun, 7 Jul 2024 05:38:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DAE4B6B0083 for ; Sun, 7 Jul 2024 05:38:36 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5F7A4406B7 for ; Sun, 7 Jul 2024 09:38:36 +0000 (UTC) X-FDA: 82312456632.03.1F80185 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf26.hostedemail.com (Postfix) with ESMTP id 9D38A140013 for ; Sun, 7 Jul 2024 09:38:34 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Do4AcDJF; spf=pass (imf26.hostedemail.com: domain of flintglass@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=flintglass@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=1720345086; 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=G7HpDLA6DyYZ1Q4ShHpQvbNumM3Z3UO1ThxB2wPm7d8=; b=WHDQkREvMVkNqI5R6MsSj/TjVYQ5dJq8dZdpVQfpmLklrCyauY5Fsxm8IBXPxdiCn8p2wa 3dQo4ubRbBK+BnSoB+wTegIrINzo0F4oe7e9n01xmJHBR3gZTT3VXzcJ3bVX+X2bidEV0S Itl2wsYZaksRi3QYc0Ot0WLJPHEQo38= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720345086; a=rsa-sha256; cv=none; b=AVNyBimr9miZCzPjYNLU3NzPADb1oykSHumLrlutFsE9I12v/aI7OKApWPzhFUFBTeWQzF MFL+VhvdDKrJUU/U28FhEQKZCXCQgKExHb933b8qPnBUJKTUlF5hHReXQh5jGxYlOYxmf6 CR9jTanLUgPGmCVDhvzAx1L6h4wCPqE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Do4AcDJF; spf=pass (imf26.hostedemail.com: domain of flintglass@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=flintglass@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-e02c4983bfaso2983336276.2 for ; Sun, 07 Jul 2024 02:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720345113; x=1720949913; 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=G7HpDLA6DyYZ1Q4ShHpQvbNumM3Z3UO1ThxB2wPm7d8=; b=Do4AcDJF6oUUZNWEYjjt1dzHHbDPN4Tz5wBxxV1InK4HcheMoZtDttMjaMxmsrkb7v +lcpgbOs3YHZKIRptYUSt7itOaORM5gDiLwxiIPSnWbJjhRCJeLbQ+Clzx/D9aEHYeKf QgcmpGUACEvmlGb4gYNBeFVa6QVYZoFagoYna6xb4MdcK5zcdPdKdjXFajWLmL3HFj0m 8rx19YXeg3SBW+2uxs5dHIPt+ohBjQ8EbXPNP/XvnhC2dP1nzHZnIlNujHRAOPehd/OX Gr0eXaht1vBB4cL2sGQBuWwSoxa9Cdqpq1aPigb/7lGxcia2y176rcTSf7SOXvmyxAag F51Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720345113; x=1720949913; 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=G7HpDLA6DyYZ1Q4ShHpQvbNumM3Z3UO1ThxB2wPm7d8=; b=tuejlwgDAICWkkvDbh7kuhwszbnpXgEjGR1W4GgvJeLqYaqBYA9SKcWlzVRRLW4qf0 GKTpzU7cIQmbGetjgX8aMbg2IvwYZ+nrkiZxQ4y7YF2XXe0RA3qKncnDtLxGbRBG1aeJ vZ9Jr9/cn9Ffqoad2kUrVRu8lUXzpYFtaY6vrpj/pW70qC+0OqvAyARj93MLxbadq4Yg ew3I5ZE8wzQkzEH5ooDPIjajwbjmgSeYz7vB9o338aeYIEA7mWp4r1xjW5QgVHE1RgAL wP0DlUzduIzIWXAHbz6A3S7X/h5R+ZPy2rHlcaUFS5PjnXHWT6tMdHTM39FuIxnv93XF bsxw== X-Forwarded-Encrypted: i=1; AJvYcCUVGp/a8MoWAnBkOXaXAkyPUDoJ8pPgeJObi7ZXqFsmt+sB+EcTZdjceE8ou8CPYthcsmsd0PfdlBYIjhz7m6opF/o= X-Gm-Message-State: AOJu0YxlEUG/Wx0Bg9QaLuZQeYc5YLUn+FXknwzlDbJP6mBJKnIiXHwC 3nSpLr7YSh69Zz20yqlSU37m6ZywnY1lIQqfCYla+gVGyIPCldHSaMpwKWRgy2WMDLpetz0ktx2 jy+iDuDK7iWHFIWuIHgMKEwbVQiw= X-Google-Smtp-Source: AGHT+IG6/KSsiO76+SpCaTPk6O2Fnb+awAIZQTBm7vTHfjoSZbMdCKO96zulmrapkD9/AV5Do8FNNeCXnHacuaCvxMQ= X-Received: by 2002:a25:b205:0:b0:e03:b0aa:99ad with SMTP id 3f1490d57ef6-e03c1a6331emr8985117276.52.1720345113646; Sun, 07 Jul 2024 02:38:33 -0700 (PDT) MIME-Version: 1.0 References: <20240706022523.1104080-1-flintglass@gmail.com> <20240706022523.1104080-6-flintglass@gmail.com> In-Reply-To: From: Takero Funaki Date: Sun, 7 Jul 2024 18:38:23 +0900 Message-ID: Subject: Re: [PATCH v2 5/6] mm: zswap: store incompressible page as-is To: Nhat Pham Cc: Johannes Weiner , Yosry Ahmed , Chengming Zhou , Jonathan Corbet , Andrew Morton , Domenico Cerasuolo , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: z96wsfw7huje8koce9zbuzm11atcywry X-Rspamd-Queue-Id: 9D38A140013 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1720345114-955233 X-HE-Meta: U2FsdGVkX18G0WEmnoGudtFhwreGjT3ZVMvIIpl0ODda0xP942vCC/T5fkqGnHOyVDvE6JsfA+JzINZA3gExyti+AEYNF6piFD7kzCy7XSHVdXgEAbbwbdTeGsM7GeP5+11WC3DnSJKEch01hnAnYUuKwVDYuAElTg2RyjfvX5ap+cnqRiVpYpXjtNBBfDUNC0lEGJmfx/VDXCMkfaGPxhfXdq0Q38iG0rmb2xyQiuJZMQty3SniDfcMgonmP3We2UFO+jHTCDVcCc7RhaN8XGvO3yITGQ1aecFqcwQOlyEIkYpudRA/6Ob5F0fi5Q52emsIZGtIfZ/GZtttYAX3I9D8ffkgKnPaNFUmq2KUi/DJpu6x1EXzsgk2w0gxW+UMIkBkb0G6zOxRcI9CPH4zDuUro7bscSgKsP4lq5Pk9aZanmFfvT4tMQxnbqJhms3GtFtF3a/G24Rf4orQVtjpGGBltI76OHlcsLswUuPSWhfxamDjhlgK/o8qZPtT1BbWSFboaFf1GtqbPs6h6qr4TOBRz7djRTbQpBdODJqV3MW5BHIkHIDXr9OiQC7mBG8KvkKuJ85Qjg+oRj5UONlN6UZwrG5pheQe6I13/AnBrK4EMMf1rzUVMysHCxvFKsB3ILqTVZPkvNYx1zfHN8EpeChoJkZdCZDr3tx4TY8tlXitcGQX3FlywcMBr9HXKx7qoEqpC+vNEL3HAYdUZA68zHndvSyV3e6QHH5skD1daJYbxJyyL+9t/zrrbAEAO44kib7yGjbtOjo6XqI723ZcoeOuoHizj0BY3qz8hqmafBJdhWh4Xnc5dwYPhUdBEJRj4Nc/F9E4OigUnzrfHuW7WniO1wysTANBK/XiL783v3yz0uvEhxhTnyzoY4tUl1mB/DH17/keieNw75grpfYbb33CwFnIDEr3PAZeShFtvAHnVJpvhAGgzhDn7zuRm2qXOF41T6pxrdf1LON/U9O 0H0jz25V V4xqUE2RO3L+Ah6agTJM10oWjMHmEcgFyFms4TqXuYi5awteWHj6lm6tLU8vezknkbdDjNvsqMYtgVMOkNQH5qaZmML3p7vpNyAm25ElZ1whkr8pPFhU9oica1rPNKRTwDh/Ls/QjBvFcrbY+wdj17XEb6mWp39F5VpZnVEZ4KbK3b3gmW0590k30JSMUEw7OXTW0VlF+65T8jiX9rETL6pS3fT6LlBH+P0HLbSX+Ccc73CHX9C3Y5WANSvmqj/qk12Bll5FTwLqslRiR1gx0b9Ja1wOg+ylbFbkdPAaT3++JDoVnShQ8UO8cmah6G27VRlJukvBOtiJv1G+qMNfp2xpq1dDMyNa850EaREmT9MSeoOGJRZmluDMV4m3fOnSW89BZ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 2024=E5=B9=B47=E6=9C=887=E6=97=A5(=E6=97=A5) 8:53 Nhat Pham : > > I tried to propose something similar in the past. Please read the > following discussion: > > https://lore.kernel.org/all/CAJD7tka6XRyzYndRNEFZmi0Zj4DD2KnVzt=3DvMGhfF4= iN2B4VKw@mail.gmail.com/ > > But, the TLDR is Yosry was (rightly) concerned that with this > approach, memory reclaiming could end up increasing memory usage > rather than reducing (since we do not free up the page that fail to > zswap-out, and we need extra memory for the zswap metadata of that > page). > > So my vote on this patch would be NACK, until we get around this issue > somehow :) It seems the discussion on the thread mixed up memory allocation failure (system runs out of memory reserve) and incompressible pages (compression algorithm successfully compressed but the result is equal to or larger than PAGE_SIZE). zswap has been storing pages into dedicated pages 1:1 when compressed to near PAGE_SIZE. Using zsmalloc, current zswap stores pages compressed to between 3633 bytes (=3Dhugeclass+1) to 4095 bytes (=3DPAGE_SIZE-1) into 1 page. This patch changes the range to 3633 to 4096 by treating PAGE_SIZE as a special case. I could not find a reason to reject only PAGE_SIZE while accepting PAGE_SIZE-1. zswap wastes memory for metadata for all accepted pages but reduces IO amount and latency by compressed buffer memory. For pages between 3633 to 4096 bytes, zswap reduces the latency only. This is still beneficial because the rare incompressible pages trigger urgent pageout IO and incur a head-of-line blocking on the subsequent pages. It also keeps LRU priority for pagein latency. In the worst case or with a malicious dataset, zswap will waste a significant amount of memory, but this patch does not affect nor resolve the scenario. For example, if a user allocates pages compressed to 3633 bytes, current zswap using zsmalloc cannot gain memory as the compression ratio, including zsmalloc overhead, becomes 1:1. This also applies to zbud. The compression ratio will be 1:1 as zbud cannot find buddies smaller than 463 bytes. zswap will be less efficient but still work in this situation since the max pool percent and background writeback ensure the pool size does not overwhelm usable memory. I suppose the current zswap has accepted the possible waste of memory, at least since the current zswap_compress() logic was implemented. If zswap had to ensure the compression ratio is better than 1:1, and only prefers reducing IO amount (not latency), there would have been a compression ratio threshold to reject pages not compressible to under 2048 bytes. I think accepting nearly incompressible pages is beneficial and changing the range to 4096 does not negatively affect the current behavior.