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 D6960C282C1 for ; Fri, 28 Feb 2025 15:56:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 720376B0088; Fri, 28 Feb 2025 10:56:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D0736B0089; Fri, 28 Feb 2025 10:56:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BF60280001; Fri, 28 Feb 2025 10:56:57 -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 3F1A86B0088 for ; Fri, 28 Feb 2025 10:56:57 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BF4DF1C8D98 for ; Fri, 28 Feb 2025 15:56:56 +0000 (UTC) X-FDA: 83169806832.12.3317380 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) by imf07.hostedemail.com (Postfix) with ESMTP id 4ED9D40008 for ; Fri, 28 Feb 2025 15:56:54 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=UTN4PPD9; spf=pass (imf07.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.178 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740758214; 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=w32+r2cAmTHBJrdauH2LehW60U9RaeZZJ4Z4Qx1e26c=; b=EmERHyvERiwCIY4iNRcmSIKnQdRDLy5W1iwNT4qrHH+rWs4llWGxajGMYFKf+qbXYzXsxG AQl25f4dQznm+mBEXZL+tSUmygSc3gQxwhi+HxWl7V+PCq89t7K8F56M3sPfmaHUZeTTd/ lLI60QoBqiP7ir2PxHxDwMX5BwMiW18= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=UTN4PPD9; spf=pass (imf07.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.178 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740758214; a=rsa-sha256; cv=none; b=GvDpT6ked4Y9sw/cVMS9lWDhD40IgxqMY12n8Ptmfx1r8ycrFMdn4+RbgXVFQ9i5FWvtWW hi+rooKdIV2sutrENFgX9Ulfg0To30tjM9zaW/7iBm0CASHUKQr5p+sZGmoHxTG7eJh5P7 nL9wi6QANU8iPf4GH72afjj87Pabt+0= Date: Fri, 28 Feb 2025 15:56:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740758212; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=w32+r2cAmTHBJrdauH2LehW60U9RaeZZJ4Z4Qx1e26c=; b=UTN4PPD9K6cdNA/dBhCcBrpZof1Zqc7KlN7i3SuhOuwZftLiV+lsdhBvtet/SU8Sdn9AAy +TpHF4BS9yWckHz+3LBj31fOavq0ph1JB7e6vCiMQIOMnXhrcmgl+dnR4PTiRkNK7AHn3n 400MXHtEuv0R4MteybvvfflrQv7Vufk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Herbert Xu Cc: Eric Biggers , Linux Crypto Mailing List , linux-mm@kvack.org Subject: Re: [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface Message-ID: References: <153c340a52090f2ff82f8f066203186a932d3f99.1740651138.git.herbert@gondor.apana.org.au> <20250227183847.GB1613@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: mznxtx1337n68mfpjo5uex41qzhm6yfq X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 4ED9D40008 X-Rspam-User: X-HE-Tag: 1740758214-412957 X-HE-Meta: U2FsdGVkX1/cavQPx9aJw9RjH8u9GnEKkOZut9GKX1TmwXMvLd4jcCrpjWMCp4hyLJoGjlYXzGXVXfLGhPWAs4DpJiiFMSG/PAdXXjBs0RkU/HK/OsyT3VOHAURPfBHAfik2GzVH5dtWlYNFSJe9PKK8iuCJVhhBiw9lNQnP/Fur12Xr0raW7n2mdBeXF8iopMlWSzCdnE67pnWVlH5ThiWKPxFZwpHIdjS0FDOHwnNZPS1oFNQAOePai4vEBrsSMxCkJJFFNvLes7gWOyOKO9nMbWJ+U0HgolM1H+MFi/w0cIud3lJ5rj6U16foUt2kKW32bcrtLrMEdfSm9bHsTjB51QYaLHc/mfCpMTIERf5bHMYs3oLp0hDL9X1ye5Vkz0Dm7N2PfQNix6l1kJe7kjPsQIm9wqWrnAKZGo6abcABNseRICM+boMThL30j/XmLoF/cAHfRyWsMJsGXXi2vxHFN9AHB7UorGVWsRairxidX97E5zkDWc2gk1Bw9LHV/YCWc1B0C0FMDaadkJNA242nhm2YE74FLH/Bydegmz3vuJCJzzmtY8BojijccSBE21zmgupA37B/ljsUQaTta8d6NOkMSCPIZtxZD/Mdv1q1MTZYVj4Eq5O4zZ3DjDkF9Q3BEuSdi6PB7tzEUaI8XGEAxgzsEd4bEbWwGpx9ply7unHLlAyAWkeUGZnJLEWtoz99mFRo7j2AuuC8dWd0YgUvekalP9TWr0cJJ/x9fDKjDmFKVPm3qiOWJVtD0OJwhrflviI6Cu4/HB7hSdUARdwyOuaeMYRZu5rX3fXbHvwrcgERSBwc8yAgkbLlsGjFNWipuvZN4Gd/BsSXmLmjtvjFA6tiqnhrtKx1QJqnN4AaofjpwwzcqMzDmILBmsaHJSOoqTSwy2TJI9GGE3kFp953VbzwmHF37RFacObVgrQir7y7pNddkKa8b/y3DVcyfwPsYY2rxTtIOI8OXxN lZN37Yop KaHUemotpqhTkoJjU8SolYmWJeR5DTDDQ/i5kPwongJHid/zRpNIzCo6SjVKHIBpkJ3EaC9IhEs3HRGqK0CgEmhzsRFur9QwNXBiOenrwjCHdIoCNYwqSPAmwDxsAm1G3KUzki7hhEeHsM2Js2+4PzZGsDiUEI6SUEXtFmwQY2HrIqeGG2HUYK3K21hLb8nfxB1XQNUzLPYuNkfKNzocW8SQ89f1CAmNO5oxpK7XXvOiQcYSi04Cug64yCN2rNy5IpQsg/qGgtUomNDM= 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 Fri, Feb 28, 2025 at 05:54:53PM +0800, Herbert Xu wrote: > On Fri, Feb 28, 2025 at 04:13:08PM +0800, Herbert Xu wrote: > > > > I'll respin this. > > FWIW this is what the interface looks like. Does it look OK? > Longer term hardware offload drivers should handle these non-DMA > pointers directly by having their own buffers. For the time being > I'm simply redirecting these to a software fallback. > > diff --git a/mm/zswap.c b/mm/zswap.c > index 2b5a2398a9be..2fd241c65f80 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -994,30 +994,16 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio) > > acomp_ctx = acomp_ctx_get_cpu_lock(entry->pool); > src = zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO); > - /* > - * If zpool_map_handle is atomic, we cannot reliably utilize its mapped buffer > - * to do crypto_acomp_decompress() which might sleep. In such cases, we must > - * resort to copying the buffer to a temporary one. > - * Meanwhile, zpool_map_handle() might return a non-linearly mapped buffer, > - * such as a kmap address of high memory or even ever a vmap address. > - * However, sg_init_one is only equipped to handle linearly mapped low memory. > - * In such cases, we also must copy the buffer to a temporary and lowmem one. > - */ > - if ((acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) || > - !virt_addr_valid(src)) { > - memcpy(acomp_ctx->buffer, src, entry->length); > - src = acomp_ctx->buffer; > - zpool_unmap_handle(zpool, entry->handle); > - } > - > dst = kmap_local_folio(folio, 0); > - acomp_request_set_virt(acomp_ctx->req, src, dst, entry->length, PAGE_SIZE); > + if (!zpool_can_sleep_mapped(zpool) || !virt_addr_valid(src)) Why is the acomp_ctx->is_sleepable check no longer needed? Also, the zpool_can_sleep_mapped() cases will go away soon-ish, so I was kinda hoping that the !virt_addr_valid() case goes away too and is handled internally in the crypto library. Right now the problem is that virt_to_page() is used to get the underlying page, which doesn't work for kmap addresses. > + acomp_request_set_nondma(acomp_ctx->req, src, dst, entry->length, PAGE_SIZE); > + else > + acomp_request_set_virt(acomp_ctx->req, src, dst, entry->length, PAGE_SIZE); > BUG_ON(crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_ctx->wait)); > kunmap_local(dst); > BUG_ON(acomp_ctx->req->dlen != PAGE_SIZE); > > - if (src != acomp_ctx->buffer) > - zpool_unmap_handle(zpool, entry->handle); > + zpool_unmap_handle(zpool, entry->handle); > acomp_ctx_put_unlock(acomp_ctx); > } > > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt