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 38B0AC021B2 for ; Sat, 22 Feb 2025 12:31:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D2FF280002; Sat, 22 Feb 2025 07:31:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AA79280001; Sat, 22 Feb 2025 07:31:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 671FB280002; Sat, 22 Feb 2025 07:31:54 -0500 (EST) 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 4DAC9280001 for ; Sat, 22 Feb 2025 07:31:54 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B50361A1428 for ; Sat, 22 Feb 2025 12:31:53 +0000 (UTC) X-FDA: 83147517306.30.4B4852F Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf30.hostedemail.com (Postfix) with ESMTP id BD0758000D for ; Sat, 22 Feb 2025 12:31:51 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=lvzCPfkB; spf=pass (imf30.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.47 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=1740227511; 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=XBQF6pBy+4ocO8lCtdZYh37OSSsL3UX8OWQxKrmEKV4=; b=u2vutSHevvKvjtuKBBvA9DA0Cm4MLmhHW2nY2FhphDynFgpfczUYN1KoSklkPAU7BmiqaC kvWk7dt/+PMWgBdVsqCUj+Sc7PtbxNG2yZxBKUOwoJx3GzN9Uxum1w4WceKQEA0XxnlM2s iC4Lg67IjmChgDZyHnbsl6fBl+e6swo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740227511; a=rsa-sha256; cv=none; b=jJYulnXBykvpkzvNkALGNRNyBtn9yo5XAIuD3ZAIIYRZNsAQaazDiG/Mgcf+DdJjmQNy+T jqZUTcppc0ntxZG500uHJUt3voM08qBJYii7pr+66AWrmClPVIa3IT4/KbuHifDYOvbLBu 8KQrELtdcDgOcJMn/Ywb087teANzJjs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=lvzCPfkB; spf=pass (imf30.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.47 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-2fcc99efe9bso4707944a91.2 for ; Sat, 22 Feb 2025 04:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740227510; x=1740832310; 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=XBQF6pBy+4ocO8lCtdZYh37OSSsL3UX8OWQxKrmEKV4=; b=lvzCPfkBA+Tq4LUoOVYJLp+ioQ56pnAk0Q8zhmmOWV0bZcDRRokRQFscpfyk7YR8ud 9oX8i4sb3e1+q7dHitRByA+t/SEFDQZr2O7pGh/wr2C20vAT4Es5EXyVfQ4E/ms7itlk rL40ENj8y90YJYx89IyowewK9VTeISLxRsLsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740227510; x=1740832310; 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=XBQF6pBy+4ocO8lCtdZYh37OSSsL3UX8OWQxKrmEKV4=; b=jZml2kupNTIjRJNYjLVIwa7lBq2VIJCtGVPh3sXiQ8ZWzSbwf2IISUFLI5t+OnPKYy baCK6/QWzEiEb/rFKVGvxicly/xqOxRL9eihwaHw7ADGuDbWdu/wFWq3jSmbAiJdQNvT 0kTXK5WhEmJEEd61PmNwoH9wQDMBKasvyIG5SJlpNizyUQfJm48W76kctKW6sQ1R9lS+ kawYev9/g27O/LPlMeV7giffqpXpJXJR3/OIQF78HOUnqBuNxBOKs662wklsFPFBrs1J G9zdGLsQ+y/S1ZxSSa5M9DXiTGIDtwsbpWrdu5k2R92DVuIolth9QyBYWJeNZYx6gBYD MrbQ== X-Forwarded-Encrypted: i=1; AJvYcCXVjbTzv9pCkbenaCBTNe0Y53tg4hCHzqG42pI/dw5+mZ1BRzvRPlcVdMnh6OdiXbb3NB7GIacEKg==@kvack.org X-Gm-Message-State: AOJu0YxpHv+oxPnyzr5emuVc27shGWHW2/f8n4xeYWXEocYbx7ddXw+W zf8jho4saW1wblHFKAKDTM4/jxN5krCuGOi09WcQ3kpuUUzh+g1V0WuvThoKgw== X-Gm-Gg: ASbGncuTw1uFyV2s2iknEbnB7uuv1vQAAz4oJ7s6Mls9xOrOf4rZD8FxZqjBllW6kk9 7rI559kpvBLESG6EXaLQpwitmFCOnoTeHZ52E+5BRq8MD7ij899IRYiF4DtEHelmKs+ovaK6Kko WdLcEC2KiFgvnpTnEMG55ZZdzjWxF5Km8z7D9ZZRg/W6Exc3I6uEJqdAk9pH1yOPu4OvRrwWL/Q lcJIv2O49LQqWi+2LPd4jDGNhdvU450niNGZmpyEvTRd0UqpDjGLC7Ea1LrAzpjQc6//Mh2c5u2 FCrsR5OvlirSTOkYczEJAue45WKL X-Google-Smtp-Source: AGHT+IEA15yK2MW8Tlp9hdnICyGJRc3eshaBlXjjjEiD2bra2pzxxjVvTfyZrcRJPMVj5WmDs2jqQA== X-Received: by 2002:a17:90b:3cc4:b0:2ee:ee77:227c with SMTP id 98e67ed59e1d1-2fce868cbb8mr9543078a91.3.1740227510563; Sat, 22 Feb 2025 04:31:50 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:badf:54f:bbc8:4593]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2fceb10fad0sm3094015a91.31.2025.02.22.04.31.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Feb 2025 04:31:50 -0800 (PST) Date: Sat, 22 Feb 2025 21:31:41 +0900 From: Sergey Senozhatsky To: Barry Song <21cnbao@gmail.com> Cc: Yosry Ahmed , Minchan Kim , Sergey Senozhatsky , 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" Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: BD0758000D X-Rspamd-Server: rspam07 X-Stat-Signature: 1cruekjb3ib7snesmk4d78gtgxwrmszk X-HE-Tag: 1740227511-402619 X-HE-Meta: U2FsdGVkX18R5ccITIvPZ5KTYAQwpBUePn/LTuo5+27q13/DbMiXa2dnIxxt0ZxSK06yEKSO/rIZi0T4NUT5OVxq8Qr8ZcWwSqtFhP4Oe39ZCyeh61VysWZ77O/JbV9pBVXAgC3empSdw0GtouRE4nGWmALEfpf28a1h0SYkyDK9kyM/Leo56MzWA+X3vrlsLDMlaT1C1Igf2oX3pjpm9tumAIKyKj84buggmBGndUhD4xKWiAIp/qXWjTpMU58XE2kiw6ofHzF1IevBkChIX6TbW67Z5bQh8F0GKWBw/Swevkl3V3dCbw35wbA017Hz5XipsabGgdTCCvxLMhKKBvrSf2T4VR2ZSxkd8754cZJ6v//eXtIaVd4Jb9598ZgqgIIxyS6NvivZ/+4P7bKPne1YdO0o624n83H6CwdA5lkz/UcdS9gwIfdUlghJwNnDz26coS2OUKppOlP9wLYUTuhCs5+RvVieboi20j25V9gYItLflETCAw2h0713QXDMHNVJ7VoSMV3/rfPphVb3CoqiAXJrGlz/KUsij4Y/uFdLP11AYYwBeK//RxWoLdvAGhwpV7/0z246HE00db3qV6mOA1+g5Zin80urhNqIXnr/21hmM3uc4phKnR1cUL79Lugy8Crg+91m6QQFp2+vuqqTegOiGy2vwJMYWX5lSlf3xHAnGGHluy1m1LnoW8E27nJbXvJhiV4Q2p5KY3VZfcS5yGwMKWYWuiCeX1wWUnZUasTXV7jXBL5NL9EP3ULcydi/+nzvjIWUo3THDa0+GrPAiUM+hpUc/DeJeU1k195deQ5+5PuzWsnvRFweQYvl5jiEEx504BReZz032FnhmaUUncfvYrRytdfSDE1MVmINs5i0tryYyQj1VkZthqmRCuvp9T4LrXjHz/Q+2fYpx11O+Lq1c6z2oRNjZipvyv8weZ+OwoPykEG8RyJb8qHiqMSbcieoxml8XrkZfj9 m5ovB3DH l4BrOeY+vslTiRTSA2HdDubW0BHJCzNTGa39+95G0SbMBjdVjegZIzRamK2BFx7n9Sh/W/6ANnECQr/D28hd35H+jYyi7UfiRQmD176fSNm5SERgXSdYJEUVUFbfC9TmJYhejNL7E5pgXlzotymV4jHrRlVULuucnT2RN4b3PPNVNEDUZKDL6Fz153DCfmAKL4gjNSI7+fL4eaBYeZnrdkYD2zanyZQXs1xuMXrQFkf8E1F4E7guKGuQW1f9K/KliPW7/0qVmJ8HI7b3LPHZRv2H162xh9ZPVW722IuBrXrR+oEdVLiEZ4R50zLeBcNUxfjagxyC/nxLhwqWaJZLBuKwBhqRymFhmdvam98k+t/gETA9UNBD0Nj0OrUICXQHU9mECuPuUHM1Dhd8C4qKN7CvNHg== 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/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 = zcomp_compress(zram->comps[ZRAM_PRIMARY_COMP], zstrm, > mem, &comp_len); > kunmap_local(mem); > > if (unlikely(ret && ret != -ENOSP)) { > zcomp_stream_put(zstrm); > pr_err("Compression failed! err=%d\n", ret); > return ret; > } > > if (comp_len >= 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 compression 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 to some random "cosmic rays" that taint the compression H/W? If so then what 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 error > 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 instead > of 2 * PAGE_SIZE? Sorry again, what problem are you solving?