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 D8605C48BC3 for ; Sat, 17 Feb 2024 04:38:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BA288D0005; Fri, 16 Feb 2024 23:38:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 14D4A8D0003; Fri, 16 Feb 2024 23:38:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F266E8D0005; Fri, 16 Feb 2024 23:38:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DED478D0003 for ; Fri, 16 Feb 2024 23:38:21 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AFE451C0073 for ; Sat, 17 Feb 2024 04:38:21 +0000 (UTC) X-FDA: 81800039202.25.DD9DDC6 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf26.hostedemail.com (Postfix) with ESMTP id 0CF86140003 for ; Sat, 17 Feb 2024 04:38:19 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GaNhS+qH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708144700; 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=M+NhA4a6o9qFXwu7cPkRfA+XqdpbAoW5f2sD+ZSJSxI=; b=1gILVTX1NITY7G6OgidrZZaGnVW0gw5+Bifxw2l87s2cDpI7nQAjLB+uwT6T2+K94gAzxv Aq5bMfMQNZcaVwVW1yE0YjEOVVvoe5K+rJVNr+RTy23c7Wz8mks8NVMkvgru8a+SZKjpKd uoEMdL8VGFTNGMBpncuGSssONiqQIac= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GaNhS+qH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708144700; a=rsa-sha256; cv=none; b=NnxSnXO9fc2HFVBCWMrHHluVlek3GjOw60kEkhx9b8Nliam2XDZvQQQXlN/sa6VIHe8vGN oFiPNpk+m8Ay7zJrFX3PuVv2d/FL/xLrsvvB4WbQgUR6JdExKeWGiCrS93T4EynBpVFiA+ puaF7CsDlxZ1e+AunKcEWK0Nk2X9DgE= Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-607d5af59feso20014337b3.3 for ; Fri, 16 Feb 2024 20:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708144699; x=1708749499; 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=M+NhA4a6o9qFXwu7cPkRfA+XqdpbAoW5f2sD+ZSJSxI=; b=GaNhS+qHmAlLeCJKoy5A/xJhShnSsolaTf7jAEK6FQz0N1+EEx6uh+yoFwOKaf88PA qQFRIW3Tcqo9P7hM53MyDfyShYq/MS8SKlZ+LyfEGVPUShzaQ7dZtjIgFMrMTsyloz6o pLGm/b0roxABVpCvXh9EGwtWTSmGSs0jx8vFs1nhBz3kNrSmWa0WJSz4iuE3Sg3RO+cn ASa2DXYPJXQIYA/X313SjY+/WRLFopC413MjPTadFxyrd3yUTbDQR6w7QRkJpjN5xcnl QORYNnLkOO/bouZHCfDsZo5xFjhF9usCWq7nOnP8JXnYQ5vkd3uWqwNXjjwsO4Br4KVU +0aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708144699; x=1708749499; 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=M+NhA4a6o9qFXwu7cPkRfA+XqdpbAoW5f2sD+ZSJSxI=; b=MMYEH8MHyMnnWpDIFLBhsHNEQzRBtQKopasNJmfxEoVqfsCHFRChIBZbke8vMldD2Y hdiWaFcL+j+EaTXIcVsjO8dhmPdLnmT8KszQ/YXIqJRCNm3e5PxLBGPlYWDSj/1E2TPX OmjzwnONbqSha2TWfn2/UakjEIxirsDusS/TN6q0UGiWeHEpb8xfv6NDQ6Bhig3bJkFo BNKjHisqIsGxR/vtFo6fX6NTlfGClZLqIz9pv9WT4UTIm7w8CKtJXTULdoag5pzcwRJx 4Q7FcFHB7MpVxSFr+mOEW/n/iI40XNmwFp5Beh8aY/lfGG95WFJYlGigylrxoVq1bEUq EPQw== X-Forwarded-Encrypted: i=1; AJvYcCVlCVlC6HNO2B0AlUvf4iBkj4md0GT8/gPPNNdIm6Ic7FeZlvVkBhmPdE3S3h3vM1WluCnxAHw1CKsVWIgwDMLPt8c= X-Gm-Message-State: AOJu0YxhdNUH0Z5vRho5LpdEanrnohyxZ/g5PmGmqNrEPw0U7HCvCfZ5 sV+dJxxncTX0PpTWMEXaxFtsmkYdcLOMakQeriPzqAqxdUDGul3YtAuaGJPpYYWm0OJLUF/D6NS M3I1veMvcyFjp64KNSW+/EbOGzYg= X-Google-Smtp-Source: AGHT+IGS+qpHho3tMY4PEOQ2B9jplodMZOL2jtEGZToyssKu8/9SyEj4bweq4W1nuufmxe8XB00oyRzbPOKmdqtdx0M= X-Received: by 2002:a81:9945:0:b0:608:bcc:3a1e with SMTP id q66-20020a819945000000b006080bcc3a1emr1184365ywg.19.1708144698955; Fri, 16 Feb 2024 20:38:18 -0800 (PST) MIME-Version: 1.0 References: <20240216040815.114202-1-21cnbao@gmail.com> <20240216040815.114202-3-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sat, 17 Feb 2024 17:38:07 +1300 Message-ID: Subject: Re: [PATCH v2 2/3] mm/zswap: remove the memcpy if acomp is not sleepable To: Yosry Ahmed Cc: akpm@linux-foundation.org, davem@davemloft.net, hannes@cmpxchg.org, herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, zhouchengming@bytedance.com, chriscli@google.com, chrisl@kernel.org, ddstreet@ieee.org, linux-kernel@vger.kernel.org, sjenning@redhat.com, vitaly.wool@konsulko.com, Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 4hy75dx8x44r73hny9if88nkdx7uom4o X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0CF86140003 X-HE-Tag: 1708144699-451709 X-HE-Meta: U2FsdGVkX19rAloevNJI5WkNgOtwglzdQ6PV8f4+1U4jDR9LGvQPzjlMapcqHJn49Y8O9P4exLtAOHkKbL9rKAMpMr2ZJiC3diX4KBo/asVD3Sw+G8s3FRj7A9dZELvGHp/OhVJkt7T6E7h0ngFJXJyzl3mF/wxLenLTJdj9Xpf/+lsSpMR5Gp0UGNCXDxzAxozF0HiulSRJdwqLRp1nkuAlG4hvYz8vo7JzqCSxXQ5cG+bVI6K1hplqntaX9QRCgqBcebhwuhYtvd676HDdLnQpUHrpSnHMf88jO3vzKN1zmkPdBoLGtgQfq8ithpQgt92/+weirO40YVGtSnP1VkeOsMxHJ1KNC10Vc5KM1NVL71fJp1u5Wru7bhHzB0fkpH2cS/F2df5ZAbdt0wBvANQ6//ZcQfTk34ZoWzoDNfQS7gmzr3j3CLrGRtJ0RRvQqxdckn+GnzUiuS3xJIPKz3RHbX5mhw3ObcFwFFGcBzOKL7nlpU7pvMkyRgwecu8SwF/OyCVFkqi/jof+Ovt/gFzYGfjQltR0yMTPqX6AcqTfpAKBd87im+ASzNrwlqO2CkEhnSPtuJIxcDadVt0aWrjEEtreACh/jy8/Lp2hFiMRUXmqKKhiqQS+4WZBOgcYCA9FUNjdUBYdQgEhcOBpaRtVI/aF3JYcl6ADCkkzulcQ9R88gWJuT7JmAGB7XsVabFNtooUf1ekPcNIiuMHGqCRL2EWjG5Po5u+UUwM5RngIYXukM09mwlN1KMcUbLZedJKiUuFFYE1ooKR/xyurtvrCFGp1tazer0KGjOtthG4/pEWdVdrozKpg2Is9vB+YQLoUGh/s8iMGIJam4KzaTQc+HzYUnOWAe/NfcGR/dxDyyOOdyvJCjCJwrlBpiVRLQXLJ0Mr3/RUU/wc7XxB7DrygDsIAnr1vGBoJoRk3OCkST+0PrNZskJRznJfHDJF1YkI+Q/DhoUEWJ0Nt8KV Z3Uw2duH HAgld51ROeyib4KcoolvaoziiuSAUu/Ek5gmp 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 Sat, Feb 17, 2024 at 8:36=E2=80=AFAM Yosry Ahmed = wrote: > > On Fri, Feb 16, 2024 at 11:10:04PM +1300, Barry Song wrote: > > On Fri, Feb 16, 2024 at 9:30=E2=80=AFPM Yosry Ahmed wrote: > > > > > > On Fri, Feb 16, 2024 at 05:08:14PM +1300, Barry Song wrote: > > > > From: Barry Song > > > > > > > > Most compressors are actually CPU-based and won't sleep during > > > > compression and decompression. We should remove the redundant > > > > memcpy for them. > > > > > > > > Signed-off-by: Barry Song > > > > Tested-by: Chengming Zhou > > > > Reviewed-by: Nhat Pham > > > > --- > > > > mm/zswap.c | 6 ++++-- > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/mm/zswap.c b/mm/zswap.c > > > > index 350dd2fc8159..6319d2281020 100644 > > > > --- a/mm/zswap.c > > > > +++ b/mm/zswap.c > > > > @@ -168,6 +168,7 @@ struct crypto_acomp_ctx { > > > > struct crypto_wait wait; > > > > u8 *buffer; > > > > struct mutex mutex; > > > > + bool is_sleepable; > > > > }; > > > > > > > > /* > > > > @@ -716,6 +717,7 @@ static int zswap_cpu_comp_prepare(unsigned int = cpu, struct hlist_node *node) > > > > goto acomp_fail; > > > > } > > > > acomp_ctx->acomp =3D acomp; > > > > + acomp_ctx->is_sleepable =3D acomp_is_sleepable(acomp); > > > > > > Just one question here. In patch 1, sleepable seems to mean "not asyn= c". > > > IIUC, even a synchronous algorithm may sleep (e.g. if there is a > > > cond_resched or waiting for a mutex). Does sleepable in acomp terms t= he > > > same as "atomic" in scheduling/preemption terms? > > > > I think the answer is yes though async and sleepable are slightly > > different semantically > > generally speaking. but for comp cases, they are equal. > > > > We have two backends for compression/ decompression - scomp and acomp. = if comp > > is using scomp backend, we can safely think they are not sleepable at > > least from the > > below three facts. > > > > 1. in zRAM, we are using scomp APIs only - crypto_comp_decompress()/ > > crypto_comp_compress(), which are definitely scomp, we have never cons= idered > > sleeping problem in zram drivers: > > static int zram_read_from_zspool(struct zram *zram, struct page *page, > > u32 index) > > { > > struct zcomp_strm *zstrm; > > unsigned long handle; > > unsigned int size; > > void *src, *dst; > > u32 prio; > > int ret; > > > > handle =3D zram_get_handle(zram, index); > > ... > > src =3D zs_map_object(zram->mem_pool, handle, ZS_MM_RO); > > if (size =3D=3D PAGE_SIZE) { > > dst =3D kmap_local_page(page); > > memcpy(dst, src, PAGE_SIZE); > > kunmap_local(dst); > > ret =3D 0; > > } else { > > dst =3D kmap_local_page(page); > > ret =3D zcomp_decompress(zstrm, src, size, dst); > > kunmap_local(dst); > > zcomp_stream_put(zram->comps[prio]); > > } > > zs_unmap_object(zram->mem_pool, handle); > > return ret; > > } > > > > 2. zswap used to only support scomp before we moved to use > > crypto_acomp_compress() > > and crypto_acomp_decompress() APIs whose backends can be either scomp > > or acomp, thus new hardware-based compression drivers can be used in zs= wap. > > > > But before we moved to these new APIs in commit 1ec3b5fe6eec782 ("mm/z= swap: > > move to use crypto_acomp API for hardware acceleration") , zswap had > > never considered > > sleeping problems just like zRAM. > > > > 3. There is no sleeping in drivers using scomp backend. > > > > $ git grep crypto_register_scomp > > crypto/842.c: ret =3D crypto_register_scomp(&scomp); > > crypto/deflate.c: ret =3D crypto_register_scomp(&scomp); > > crypto/lz4.c: ret =3D crypto_register_scomp(&scomp); > > crypto/lz4hc.c: ret =3D crypto_register_scomp(&scomp); > > crypto/lzo-rle.c: ret =3D crypto_register_scomp(&scomp); > > crypto/lzo.c: ret =3D crypto_register_scomp(&scomp); > > crypto/zstd.c: ret =3D crypto_register_scomp(&scomp); > > drivers/crypto/cavium/zip/zip_main.c: ret =3D > > crypto_register_scomp(&zip_scomp_deflate); > > drivers/crypto/cavium/zip/zip_main.c: ret =3D > > crypto_register_scomp(&zip_scomp_lzs); > > > > which are the most common cases. > > Thanks for explaining. Ideally we should be able to catch any violations > with proper debug options as you mentioned. Please include more info the > commit message about sleepability, a summarized version of what you > described above. ok. I will enhance the commit message of patch 1/3 with the summary. Thanks Barry