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 BD5CCC3DA6E for ; Mon, 8 Jan 2024 22:36:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AC0E6B0072; Mon, 8 Jan 2024 17:36:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 35C356B0074; Mon, 8 Jan 2024 17:36:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2250B6B0075; Mon, 8 Jan 2024 17:36:34 -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 124DA6B0072 for ; Mon, 8 Jan 2024 17:36:34 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9C1981C1184 for ; Mon, 8 Jan 2024 22:36:33 +0000 (UTC) X-FDA: 81657604266.15.FD3A281 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf01.hostedemail.com (Postfix) with ESMTP id C635D40017 for ; Mon, 8 Jan 2024 22:36:31 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=W2O6gZnz; spf=pass (imf01.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704753391; 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=Kp/QQnU6OqH2UQyKTVh3F3K1n7okkdJ17va/Cb7sw4E=; b=6Os4OILHN5Qagg/rIARuo5IotPWNIvIyJYkoF7za6oB2IHtWNoKXEl2tFzeokaECypbne+ xKYb6+YncfrZr1H7sR4Ei7R7GNyXMCnLblnvFAfZrLMawSQ624xcWpTpDUObgdMPy3Bfds L/HTo2yDyDbW90zZ62i+2B4Ava1fxEI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704753391; a=rsa-sha256; cv=none; b=vo/djDNKnVcgH/MObU316Cttdk9eb4mNBFWLaS4SsQbIccXnfHVvn1lNjxOcsRSEvCmaxm VNEl6G1wMNW8MoqA6ijXgt1wnJlje5ymb1SMt9jv5nFB7Oq7hXgbyQS1hyl875/dS0zSWp Cg4+Y+Fp4K/1AgiD5xaFt6zZofenGD8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=W2O6gZnz; spf=pass (imf01.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-55719cdc0e1so2626160a12.1 for ; Mon, 08 Jan 2024 14:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1704753390; x=1705358190; 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=Kp/QQnU6OqH2UQyKTVh3F3K1n7okkdJ17va/Cb7sw4E=; b=W2O6gZnzqrzLMLLEG5sLLYH8u7MqA2GkJDR7FQLPH1+3Kld27m3Ozf8YuWMhtxGP3Y aQrTBQ6/zkusv0dJBuJDnIC2rex7qmuxj148Twy/OMvkyB70x1GqakUCaEHYjQ881rxJ oe8u40NSO8t6ZZts18ms21HaMO07AAxc2aVlTTCExsMgNN8gg3Lql8oceQLWMM+AdXJY d/Wlf0YztfOrO5V0bNYrGByV+Faco4MH8qh1VrbqnxB4WSgasiAPVHIhb/2klwA/NHlN FjGZWXzOL35Ny1knGJKdQyIEYAGDUTmLhsQKqVTPhd8dIR5Sbez6z7cdsjCutcBYESui 3RQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704753390; x=1705358190; 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=Kp/QQnU6OqH2UQyKTVh3F3K1n7okkdJ17va/Cb7sw4E=; b=nz9YpEk/M1h+c3RtJzxRm/Ypr6FTZcLh4kO7/M9+nbdLDudp0N//Vub0J1a8GUSRwR RuKYK2T1WCKpdUe15cwR06q+pb3tL2r+4/reGAQWJNgD87BPzUErQkifComfByflaoOL lg7F0ZOFvN8bgB0TaFFqDS7mucD7M0VTvXg3wmJr8P+GzuxNm5Z2F2Or1dsCdGJyqU0R 0daD4hnoQanRjNjOxzS7cBDRV8R01cdW7pAdU7NtdUHWDmeUEc54LNUV0466ZywGvmwm FxUoRoV6k9iRDgkvztaw5/6hH/E0KOLxrJuX6vUgtHP6XjXmQvcjsMU9JTtYbKG+r/g2 A2wg== X-Gm-Message-State: AOJu0Yz8pjxQAiVOaWHrxxXLJJQT+8P8zwNTnecCL0cjMtxyJcpqSwJa acVJKBiB6RB3TTsmHnNb/gqLCsS12fqlfDj0nlLh8bcs0nM9 X-Google-Smtp-Source: AGHT+IH+01LiTm211gHpYVG2JZGM4SZKJyCiWiRXlviOXt1CIGYMdgBB979VmVNEKNlDdlkYtoP8P4P7IWI7ndK8mo0= X-Received: by 2002:a17:906:6d17:b0:a2b:1efe:fbf1 with SMTP id m23-20020a1709066d1700b00a2b1efefbf1mr59532ejr.89.1704753390154; Mon, 08 Jan 2024 14:36:30 -0800 (PST) MIME-Version: 1.0 References: <20240103095006.608744-1-21cnbao@gmail.com> <20240103095006.608744-2-21cnbao@gmail.com> In-Reply-To: <20240103095006.608744-2-21cnbao@gmail.com> From: Yosry Ahmed Date: Mon, 8 Jan 2024 14:35:51 -0800 Message-ID: Subject: Re: [PATCH 1/3] crypto: introduce acomp_is_async to expose if a acomp has a scomp backend To: Barry Song <21cnbao@gmail.com> Cc: herbert@gondor.apana.org.au, davem@davemloft.net, akpm@linux-foundation.org, ddstreet@ieee.org, sjenning@redhat.com, vitaly.wool@konsulko.com, linux-crypto@vger.kernel.org, chriscli@google.com, chrisl@kernel.org, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, zhouchengming@bytedance.com, Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C635D40017 X-Rspam-User: X-Stat-Signature: romhmxemnscaydnx91ehnpnthp69hmit X-Rspamd-Server: rspam03 X-HE-Tag: 1704753391-170990 X-HE-Meta: U2FsdGVkX18JI7w4WGw77h/0kkk/3ShfSjmGClrWuAbmP0e4K6I0SvQp9Ux9y3vzV8dmeVcUQdj4nRcM9ioOgNE6Y+u2WTaSWG8ydhtek85/73ejWbBZqJY3JEaxUUu0IC5t8tH0E/7HRwlLw3ryChTo0ZhBL4s79J87WQ9UJ6R/2aV1TYV6+l0U3IYzi/k8dc0CXkf7IxD87XAj4cLvPNf3xsThrqVAAiAztUBB/3M90GeaePWHYqcX9+48KsK2xeYIbLTxs89+7ZLJuZnQ7e8IC/EkqqRUKo3vY9b/h1omSjoZuF50OtwAXnnjegSe2G00gKH8tYKUAHLF4SzhA5Wu4xXZSQRK+y+DmvdcQ7znLHrPAW4yuY3VWkVjOdRjDTQWgAEnvxMzEJX71abSwl8YB7RZv3aQ2ZpN4zLQD5FH5qXt4XMmdtv9oMVuYKUAdDbywOhAjQ3zI3BwODsgEYROFerbT6dQ+lCBp5URfJzm2erYKXjSWD55WrOzc4/2IsaZfHo25Ru5IT2ai3MhN5+VzmCJKDldNsBEIgKsQ862uDCREGpK/vBQUbgEL4l9/44lCNpNUN0PFghinBpMRg2sb6z+bs2GLZnxab6xM0QnuzfCTU24WY8aO55nQLeViMWGt0MLd0KuqRi9f50quW/8QbJK56QKfR3GB2jTDHMmhQY3HzQoOAzjVtyl4i/uI4DahTUTb5OuayIs9pkH/XZI9P8H80fwNx2DtVtVD5Pz5mR9zegJnyVVI01ZfFstR57qR/2H1pzTjVDn6zssepXE22L9Wpc9MzsTxpib5J2mNeT8/+EFpW8NMH7WWSu/tFegtyLgv+wmfG2bvMh4RbfbuPib/smZJuZlw1yGUJw+sThoCCHzb6LE7Lu85fKRk3m91kAZMbBqptkFDfi5HtnW78cpwMXzzRQpme8u9fq0D6OyynvS/U6BHN/ZdftWnSBdinh8ErbjzZ/Cupw qWKHH2Z3 qIJlD1W0xlPKAKCcNm1wP1aQhGjazqdJi+xiclIbJB0mcZQoLeKFKnXcYzSh1xeFMF1Hb2f8Brg1zAhUTyp/o2A3xneaForuc5pynYeTCyhEFeAwvU4P0G+T1sgI0I9hCvmXjAMWcPg7196Ic49U95io5XJQFrALyxWmoZEy1kG7Cz0EUceoamHVNgBRwlbnxMpBn+6s+ntA9B8T4z/jjG9yHcvyk9QsL86y7uPwRqLuKzFZ3Yx/s7SL4+0a/hDYhbTxC26uH/gququj6Ze/2ycZuawDOzlEZ3QVfwFkmd1n1/ZUfAI0yD0sNzIrbXNJLonyCrGTPqRUDH24qcdpbaBDFL6/i0loGVNt8105LXgbRE8nBSzN+hQiXZKnoyNM+1jYcvsqfOsZ+60oIdYZZAuPus/nDG/CjBD2mWUmstYnB29FS1g3RjZxeWN90R3Z6XBzH 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 Wed, Jan 3, 2024 at 1:50=E2=80=AFAM Barry Song <21cnbao@gmail.com> wrote= : > > From: Barry Song > > Almost all CPU-based compressors/decompressors are actually synchronous > though they support acomp APIs. While some hardware has hardware-based > accelerators to offload CPU's work such as hisilicon and intel/qat/, > their drivers are working in async mode. > Letting acomp's users know exactly if the acomp is really async will > help users know if the compression and decompression procedure can > sleep. > > Signed-off-by: Barry Song > Tested-by: Chengming Zhou > --- > crypto/acompress.c | 8 ++++++++ > include/crypto/acompress.h | 9 +++++++++ > 2 files changed, 17 insertions(+) > > diff --git a/crypto/acompress.c b/crypto/acompress.c > index 1c682810a484..99118e879a4a 100644 > --- a/crypto/acompress.c > +++ b/crypto/acompress.c > @@ -152,6 +152,14 @@ struct crypto_acomp *crypto_alloc_acomp_node(const c= har *alg_name, u32 type, > } > EXPORT_SYMBOL_GPL(crypto_alloc_acomp_node); > > +bool acomp_is_async(struct crypto_acomp *acomp) Is synchronous semantically the same as sleepable? IIUC synchronous code may still sleep, at least generally. The purpose of this change is to know whether we will sleep or not in the zswap code, so I suggest the code should be explicit about sleep-ability instead (e.g. acomp_is_sleepable or acomp_may_sleep).