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 F27A9C021B2 for ; Sat, 22 Feb 2025 16:24:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62D476B0082; Sat, 22 Feb 2025 11:24:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DD026B0083; Sat, 22 Feb 2025 11:24:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47DCB6B0085; Sat, 22 Feb 2025 11:24:16 -0500 (EST) 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 28E356B0082 for ; Sat, 22 Feb 2025 11:24:16 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A4E608182A for ; Sat, 22 Feb 2025 16:24:15 +0000 (UTC) X-FDA: 83148102870.17.62EF6A7 Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf20.hostedemail.com (Postfix) with ESMTP id C1A101C0005 for ; Sat, 22 Feb 2025 16:24:13 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YVa+eLcY; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@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=1740241453; 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=Sav4wPG9DWPA9l3hgLj0gOmAeBsfhnABFgdC6wlWJKc=; b=koTcyhN6rk48DvZ8gNk/0nSQ3zRg0YqGWEd6oaRwqFPTI7u49oZ5R6fT+b06kZrW0rvZTM ua8n394+rd4rYUqkxlw/OYHfIGW5hYFdzkAlJtg0Mul1OW/EiWUCf8RNKAnCUsdK464hpM uzWi480aMxelzI8ka3QRlh6+fcIFQHE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YVa+eLcY; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740241453; a=rsa-sha256; cv=none; b=whr6hlYYmBcwD35a2BV4/SLWHfmYLCPYmH1COS85Rbvbs4vUbBroCY91XKmDBAdpNOBkrk 460nVSXM2NvEvPGeaz/RwHXbwefDeNkWNA+uXydKSlhPNxQw8aZGI3tktCFCdy2pF/RJjH Sn+CyNSla+gEbOi860FWI77mDrFXf+0= Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-866de72bb82so933491241.1 for ; Sat, 22 Feb 2025 08:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740241453; x=1740846253; 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=Sav4wPG9DWPA9l3hgLj0gOmAeBsfhnABFgdC6wlWJKc=; b=YVa+eLcY9Vuf/KzCTFxVz/afG9Y5aHTmHUpAnJVYGvgvPFvnYL7tUOOieMfy87WRBy vg12lbSeXB5o803sOjGNyJDqNVd0T708HYNM+Nh6KCLQfnx46VIsi3+SuRt338ERajl7 18YLUL9pSYw7XOEHkmffxs9eBta7MK36IoNFUuonAjqI5YoFwk4rRinFoHGaAwf8HHQG /a1la4lPiQWdKCMSzVkGWh+EKkMGyBjyWNjZwJwwb2Ebj2DbXmfvbPGRiatPEMV1smm5 krblzKOSmGWRIQyHdmqrdkzjn7Z3O4SRA6u03DDlm0K4O2XqI7NRiB5tN9KFUn8Y+ksE 6X6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740241453; x=1740846253; 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=Sav4wPG9DWPA9l3hgLj0gOmAeBsfhnABFgdC6wlWJKc=; b=Q99G+3gs03zVmK6dHsZ+yIEknsghpZWAyhBo9UyeAC06FeZ0XRpvjADET8k4dn9UaZ ITfA1pegaDtBooj8EP6cF2WrCTTtEwH5VhhDTwrlDtD+FXA4t/jt8uok80375+DhhHG0 UwDDBsUzGTVf4QTPVdyTI1qd66Wod1ltxuzk7Xo6UDTNZAkfbMIc1beuLSeweNeyJuol 6lq9wE0yNYuFjaG2rwlGWOBPwuAlKRMGmxOYPZN9HhNzHRjt3EcmCZ49pw3NYqR4Fx0v xUIxb0wtjm98XXXkFeNZLKLE6+/1dfkjdoRDyDWtEiX1dy2Qm3+nqdqrL/TIP/JULyyH duVA== X-Forwarded-Encrypted: i=1; AJvYcCUEI0aPNXXTF75cu06SBo58bBki0kBUBtabHVGf0imrvcQJLWqoyD5Z4av7s6xEXhngRXkzovsesg==@kvack.org X-Gm-Message-State: AOJu0YzZYXGKOwcP8qGlOsIw6v6CCQ8uFmzv5wT4EqyqMd5VtPlbQH1G 4A54xSFuq5kT5YOy344LmUj5wyQqKOogLLGDdMJC/5vf3z+Or7xcPe5hFybJz82IAtH3jdmdZbE J4ualqWJrizRemOAEwUInjPjwDdg= X-Gm-Gg: ASbGnctKlN69PfwRKXSZmzgvTneSuJsFAR31MMOCi1rOXG5sTfdV5pJlklW61NfE7a0 InG3HUm/KNQdaT4KZZK8r8LHdtV6cX+iyyQy77euQBKov0ABsqH/IWJ3rcZdXHpVnGY4hxCFO0u gTNykLfvg= X-Google-Smtp-Source: AGHT+IExbeBvFGtjLuoasW3NeMshCokZaIOyTX2uf0zaf0oAM379rYmGJUT6WjsAQvdQ7FbzFCOa+pXex4aBHc2E+YA= X-Received: by 2002:a05:6122:ec3:b0:518:6286:87a4 with SMTP id 71dfb90a1353d-521ee253c9dmr4720213e0c.4.1740241452732; Sat, 22 Feb 2025 08:24:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sun, 23 Feb 2025 05:24:01 +1300 X-Gm-Features: AWEUYZkxRypvz8LrhfnOSKOPJoiE7CkvYVgqyhi-wM4RgZJZyCSAVqDgM3Nysw0 Message-ID: Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching. To: Sergey Senozhatsky Cc: Yosry Ahmed , Minchan Kim , Herbert Xu , "Sridhar, Kanchana P" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "akpm@linux-foundation.org" , "linux-crypto@vger.kernel.org" , "davem@davemloft.net" , "clabbe@baylibre.com" , "ardb@kernel.org" , "ebiggers@google.com" , "surenb@google.com" , "Accardi, Kristen C" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: C1A101C0005 X-Stat-Signature: e5cjj3zxb3rixa85dp7cz9yfkipwiqp8 X-Rspamd-Server: rspam03 X-HE-Tag: 1740241453-928308 X-HE-Meta: U2FsdGVkX1+IwitqM67HIo/K2+nanLymHnP3EYhQCDAJv1Gmpj2K0OSLsJvxnh3HaXRuJ9XLSLNj2fBz3ToRJdrN6UN9hAJZ+CcZ7wzx2tX4i4dC0RM/3ejR8Otg2F/mmXH0p5Z3Eqa8r9n5Lfcjp5LUeQJJdp4/SVrGfyjTdLKZ+Bl/Rh+8iSZhBjJRU0uEV6ELtyPW/xrL1HfUMjBePXXFHG9pJQw9xwJG6bZ0RNNiuiPR5MdPSJFcb6haclpBFHUqa7jDmpLYtDdQI+xCQrBhGiT/tQmhys3DvSss9p+cEV5F5R38zT7PjgAhg66o63g9ly4m4cYH0317JM/Mc5UXemJg07t8fivGfY0Id/BUagIx9bYRe0aJeMsc+d2j8Qt9H5hK5fdx3iPeWK9WH0g2N/nbMDAqtKPT+zUK8xhqGNtfSjayMQVdgS5/VJpbQWbXu832hxywoAU6ybu9QdbT1AnGqorZqin8BIITfOS6lw/ZBOXkDK75JfBYS6wQ85xl/Xz+otTu/QowXzm6eW0NyGgPPu6fDiWd5VhnmPmTVUxB3y38ahH8CmrKTa7txuoNcfN9bZmw7dv8zBdzWQ8s84kJexDbWF55Qmoh4AARXk8EtPqEYYZ+QbLQB0P6I7neDUOD2PKlGfDEh3Rpsgu2NMp/G6M92zaF18O0AgKYmPa0Zf2wv9azrZvCDx3BtfyA8zu2AXQNZsTR+vZt9UgACxXwc045zztxka+a5xZtGT1qZBnSpHsYI6pVivqQjxh/iRTTAwtp6oEw5q6+bNK4LyAl7n8WfwbewqOx85mIzcRnjvu/ITC73h4vrydeVzNDFmgNJAMYJY1o/5l+7RgIoes4jUPA1ofc8RsT9Vu63cj9MnBmRttQBMyzkwrRfJP3Bem2y9qG1E3VQQqyHn75NAtHwvVVJy0P94mO06/dz4OD+d0Y/lQ+uVjFCcEWu2TIgxtWh9Thm1YuJZ5 heRNMN0X RwAbWSncYu2/2M7gZUy3Ymkvf0UofaFwwFCfpOEm/EDyGO5wJdkB8Rlfh6u5gxRHxTfkz7cN90JAfQSwycoVOAZHW4RKwz20iLvQP6mGmPk6yeHi/3dLHNq4mVT0f88wIU8de+lUeBf+qoOnK84nV6zM2DyQCBzZtTxNYvvRSnUkbxSRPDrug2Y128VgOawErw6J7rvgK++Gbvo6Ph96wVATLnZK+2nEGL0UJ5QW/boz+TSJ3ulyIXD5AZAWfeEvB0PsyG0XkejNmPymidYiY4kRtcarCoApz/tDfIYQ0JgsAQU5RP16LUITPZ8nd2Y871F+q69nr4q+Xuop64gNgI35hO+KopnNg2GWC5dD4QNKCD7ABF11EqsGYtlOGu9hDC2+oShdsdQQyPoW8RlKYg+OnBiWUW51LBJ8uYpS0kXaTTmRuiXN202p0VUXn6Mo5k9KAnUyK1HCCpwXKhaLHEZ5D9d686TRY0FsUONYmv+4Ritw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.006276, 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 Sun, Feb 23, 2025 at 1:31=E2=80=AFAM Sergey Senozhatsky wrote: > > On (25/02/22 19:26), Barry Song wrote: > > After reviewing the zRAM code, I don't see why zram_write_page() needs > > to rely on > > comp_len to call write_incompressible_page(). > > [..] > > > zram_write_page() > > { > > ret =3D zcomp_compress(zram->comps[ZRAM_PRIMARY_COMP], zstrm, > > mem, &comp_len); > > kunmap_local(mem); > > > > if (unlikely(ret && ret !=3D -ENOSP)) { > > zcomp_stream_put(zstrm); > > pr_err("Compression failed! err=3D%d\n", ret); > > return ret; > > } > > > > if (comp_len >=3D huge_class_size || ret) { > > zcomp_stream_put(zstrm); > > return write_incompressible_page(zram, page, index); > > } > > } > > Sorry, I'm slower than usual now, but why should we? Shouldn't compressi= on > algorithms just never fail, even on 3D videos, because otherwise they won= 't > be able to validate their Weissman score or something :) > > On a serious note - what is the use-case here? Is the failure here due t= o > some random "cosmic rays" that taint the compression H/W? If so then wh= at > makes us believe that it's uni-directional? What if it's decompression > that gets busted and then you can't decompress anything previously stored > compressed and stored in zsmalloc. Wouldn't it be better in this case > to turn the computer off and on again? > > The idea behind zram's code is that incompressible pages are not unusual, > they are quite usual, in fact, It's not necessarily that the data grew > in size after compression, the data is incompressible from zsmalloc PoV. > That is the algorithm wasn't able to compress a PAGE_SIZE buffer to an > object smaller than zsmalloc's huge-class-watermark (around 3600 bytes, > depending on zspage chain size). That's why we look at the comp-len. > Anything else is an error, perhaps a pretty catastrophic error. > > > As long as crypto drivers consistently return -ENOSP or a specific erro= r > > code for dst_buf overflow, we should be able to eliminate the > > 2*PAGE_SIZE buffer. > > > > My point is: > > 1. All drivers must be capable of handling dst_buf overflow. > > 2. All drivers must return a consistent and dedicated error code for > > dst_buf overflow. > > Sorry, where do these rules come from? > > > +Minchan, Sergey, > > Do you think we can implement this change in zRAM by using PAGE_SIZE in= stead > > of 2 * PAGE_SIZE? > > Sorry again, what problem are you solving? The context is that both zswap and zRAM currently use a destination buffer = of 2 * PAGE_SIZE instead of just PAGE_SIZE. Herbert, Chenming, and Yosry are questioning why it hasn't been reduced to a single PAGE_SIZE, and some attempts have been made to do so.[1][2]. The rules are based on my thoughts on feasibility if we aim to reduce it to= a single PAGE_SIZE. [1] https://lore.kernel.org/linux-mm/Z7F1B_blIbByYBzz@gondor.apana.org.au/ [2] https://lore.kernel.org/lkml/20231213-zswap-dstmem-v4-1-f228b059dd89@by= tedance.com/ Thanks Barry