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 3687FC46CD2 for ; Wed, 3 Jan 2024 02:58:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF6BF6B030B; Tue, 2 Jan 2024 21:58:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB0FB6B030A; Tue, 2 Jan 2024 21:58:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F9AB6B030B; Tue, 2 Jan 2024 21:58:31 -0500 (EST) 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 852DF6B0309 for ; Tue, 2 Jan 2024 21:58:31 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5DD8F40772 for ; Wed, 3 Jan 2024 02:58:31 +0000 (UTC) X-FDA: 81636491622.02.7C7033B Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) by imf05.hostedemail.com (Postfix) with ESMTP id A68A6100016 for ; Wed, 3 Jan 2024 02:58:29 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bn4iOZPu; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.47 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=1704250709; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/a2j1/lHth7zs05WU5aYt/LfzS3M/wGNylwLFfEgkQ0=; b=PAO9o3PYskesH6hoLy1ZHgdR3B863wGEsvOa512oPHU3VRRziaFZ3IcORfnnFIDyEUyTCe 6HkyvbE1vueVGz+p2iOi40pPPsB6KGjUKy4Dl5IZfJTBOKBTa/EWD3rH6PdedInSE2tEXI 5ASjPAikhSsUHlBOgAMdlPlnTQ3hMvY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704250709; a=rsa-sha256; cv=none; b=XacXxvATgFVYWfl+6UeuqYN85g4hoJtim7gFr45l3S3zUwbGVXyDIE8jfeEwL/LSdbq1mB VxZKkVXL59b8cNcIT7zUeVS13BFE3WfASQ/RS62DhwXbtWUmJ6hg5EumGtEIcGL4KO2T5O g/T7+/NMb1OkUCPKvMQ3L4c5mHA0uQw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bn4iOZPu; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ot1-f47.google.com with SMTP id 46e09a7af769-6dbb7d80df8so6867729a34.1 for ; Tue, 02 Jan 2024 18:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704250709; x=1704855509; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=/a2j1/lHth7zs05WU5aYt/LfzS3M/wGNylwLFfEgkQ0=; b=bn4iOZPu2AI4620di8JiZYxEUeUN4K4jjgMxSIbXT67Vg6c7qhh+eFy7iw3ZqlkZqH BjHw29skKb/N10xgySLtuiMobAxYauIU/IrlIvmhSkvS6pnZEAWUgNdiLtnqjRxAHktq 5yQynl7U+YCDN7cIFw5b7c+h0o7Hav99Yra/VeMZEQrcB9vSDhsnV1fz8fZkBRmJKM+y vCrQ3pyLSow4luS/XkvRK5GFtPpcL5dxLO9qWzzrOiTFrC/7z+4Ftog22l5VWkVvSlzt L7tqV8RV3vkd8ro0GF+29lOUTVOEL0YWiyI6Lv+C9Celqrtm1UdRMk9B87W8XfsbR/EW OBGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704250709; x=1704855509; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/a2j1/lHth7zs05WU5aYt/LfzS3M/wGNylwLFfEgkQ0=; b=I+TAhNzHu5qdDPcNflsal+dFlXpuzvjn+jIe/iNk40h0Zsnwerd4jKU1FfAhayFjnW QDfnfF6spLQhYuTT9VjzzEQI7gcJFNh5F+ceo37SyGL0WzTKe6u8pPJ0QAvcOxS0YTmv oiWqiKMTqD8KRhrFRShDfooYjLkmD3vgbjRAtnvU71t3K4Gko9M5J5FF4aMYskNNV4DT 9Bs+viEYUIVYEhKmC96AOSzSPaBb3bxpNHSVxp0K2Xs+oMibgne9oX8Q0S87c4X9jP7N PxewZ5o3vDaH4CTSwMxTKEc4y3R7Ux7PWK6rFAuMbNjYdwaNV+qw9oH6GgQUQT/KFiNq Bqnw== X-Gm-Message-State: AOJu0YzKP+wGISHzFRCRE5a9NQfsUSUd0nZrKQaWpPUJXsgzFI44eBny 0VPd9P4WP2Nl+QkVn5AOKZ8= X-Google-Smtp-Source: AGHT+IFpg8o2SLVkvafPjMs9qtDK8eJP522pJiWlxctRpEYR82N3yz/UoeW+DRyVcdlGAEybzkOYvw== X-Received: by 2002:a05:6830:3:b0:6db:fd12:8e9c with SMTP id c3-20020a056830000300b006dbfd128e9cmr9353263otp.5.1704250708788; Tue, 02 Jan 2024 18:58:28 -0800 (PST) Received: from barry-desktop.hub ([2407:7000:8942:5500:a7d6:f37a:9130:cd96]) by smtp.gmail.com with ESMTPSA id d6-20020a63fd06000000b005cd8ada89e5sm21168572pgh.70.2024.01.02.18.58.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 18:58:28 -0800 (PST) From: Barry Song <21cnbao@gmail.com> To: herbert@gondor.apana.org.au, davem@davemloft.net, akpm@linux-foundation.org, chriscli@google.com, chrisl@kernel.org, ddstreet@ieee.org, hannes@cmpxchg.org, linux-mm@kvack.org, nphamcs@gmail.com, sjenning@redhat.com, vitaly.wool@konsulko.com, yosryahmed@google.com, zhouchengming@bytedance.com Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org Subject: Re: [PATCH v4 2/6] mm/zswap: reuse dstmem when decompress Date: Wed, 3 Jan 2024 15:57:59 +1300 Message-Id: <20240103025759.523120-3-21cnbao@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240103025759.523120-1-21cnbao@gmail.com> References: <20240103025759.523120-1-21cnbao@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: A68A6100016 X-Rspam-User: X-Stat-Signature: trzizrkxyarp15r5nbygnbm5aq9i7jon X-Rspamd-Server: rspam03 X-HE-Tag: 1704250709-619303 X-HE-Meta: U2FsdGVkX1+KEK2DBN0qpZFzYP6gJlefCwtH1+y3FNkNzRRweQOMCOc1UqU9Tr1/3nfw3I7113MlpsKUltU1zOW2XKd8drEkPx+xYe7KJH3jXO/xWOSLPGvXwlQk+xu1q9aWd23bY8hPZmHIjwCl3wkDVctCYYf8IOroVs8aFobUr4lLkSBYcuuT6ddlGsexhN9SDTxfwlGkFGnQOgKcumAqoaAQ1s02FcYgz4ZCG/vXrxnJTh6SKIu1osc5DLrLXqTACXQguZnj6Qk+KmeA/Aj6x4Vuy2mEKB66XPVN1dH79MZJ4FNRuLYjz2/V/kbJKmqOC7iHqXb4+RX3kKeMWdSYU88bRoYVBxYlDRhDmTqDSpApiIFXRgnq2STyhayaKH4ggDA5AgZu+m/c/7Etlfd4zr+JDaglHhNyOfGu7Z4cKCAmUTrDX16H/5ZhweO5d8quqKXzq+2aGGtuRDKsTUT2ZxfB3bJTXcDn4B18asYyfmnXeGt0N8L++CJdnXOXFtg4uLFINIAW+6eYs37A5Q6MG2sNzLwvdEgGMXoNHL8Do0toMiRKseSgvIpI6s3XEhCdFM8xhpLVx/2QMFA7weRvZBYK4Q2UQ0ciCeoqIBJzbybh+g5VTDSh8Xobuq+eaEcRB6GDSw7LHjchuU/HSIKB8BkHLhan53GjUJMM9x6QYu0S7+zMVAv5LUnvD2TvVTYD+s+GvJfQQnekgaG2H5CayRlFm6JEgRAFRsyRzdZgWOQQwRpbHzKbq/B4dV7nAlNDKvjuop0J/GViVTfJSyqzpn/WJtR1/xlBF/OofG1a6Pv85ATmp4hu08ALwXKnvykw3VwPeUI/2uKohiNHEgyrdKb2aawXVPBeb+N95zdj1v4oOKFa/Qie+fwcI2wvoKUUfZ3QYyuowb1RmyF2Ft7mXPGNaBBgK7VnNBAzHp7pmOAWQtTviKZLh2o960VhuSKSjjF/7I7ZMj7cq0t EFxjNOcb IAa8/uCyNvhGi198Oo3nevK1bjf7gXf5K29Il2gjnEkCsl+YVcmKfKvopeFcaGzQK597nekpug9lKzhR1Fj4NEbLTLYJmd1T9HdCjgTubK6qA0ro/XhspVRMz/FuA+lUT9IWNO41U1mR+FKBl/rGW11x0a4wFOYHz3tS6RmP2TqALc0MmSWGJBLw2zFvhjdCHDvBjoRFonDikNfnLt5IvnRqw4bdZ9yecess0ekZHoVgMBqDCfUyOhXUgW8f3c0qX8JcHm36ove2801QzIRvrRViFCqnGZ9Xge6TLrIaePuZd5cpdohWOd6964SLFHgpVfkQSVNQ6y4RzAXbK0+5QcgaRyw0eP1YTxPtkSclmF4gekREqRibI1nmCLDdxVmeCG6pRhKqMT1PVpGpV5RM5I6skxdpw0FInXqkIGYxZVvepedmBcZXNg+Cbk4XoN1O+Zf6i5wZEBJ+mWxf8KZ9MdbHda5cwp35edMORzMoT+V3Y784E9lXMewjzaGDLnLhYYfBAJehBCK5U/sm7bfIFfmBBepQzS1fsmI7sfO86VYWlqWk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000955, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: >> >> for CPU-based alg, we have completed the compr/decompr within >> crypto_acomp_decompress() >> synchronously. they won't return EINPROGRESS, EBUSY. >> >> The problem is that crypto_acomp won't expose this information to its >> users. if it does, >> we can use this info, we will totally avoid the code of copying >> zsmalloc's data to a tmp >> buffer for the most majority users of zswap. >> >> But I am not sure if we can find a way to convince Herbert(+To) :-) > What would you like to expose? The async status of the underlying > algorithm? Right. followed by a rfc patchset, please help take a look. > > We could certainly do that. But I wonder if it might actually be > better for you to allocate a second sync-only algorithm for such > cases. I'd like to see some real numbers. some hardware might want to use an accelerator to help offload CPU's work. their drivers are working in async mode, for example, hisilicon and intel. I don't have the exact number we can save by removing the redundant memcpy, nor do i have a proper hardware to test and get the number. As Chengming is actually working in zswap, i wonder if you can test my patches and post some data? > > Cheers, > -- > Email: Herbert Xu Thanks Barry