From: Yosry Ahmed <yosry.ahmed@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Nhat Pham <nphamcs@gmail.com>,
Chengming Zhou <chengming.zhou@linux.dev>,
Minchan Kim <minchan@kernel.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Yosry Ahmed <yosry.ahmed@linux.dev>
Subject: [PATCH mm-unstable 2/5] mm: zswap: Use object read/write APIs instead of object mapping APIs
Date: Wed, 5 Mar 2025 06:11:30 +0000 [thread overview]
Message-ID: <20250305061134.4105762-3-yosry.ahmed@linux.dev> (raw)
In-Reply-To: <20250305061134.4105762-1-yosry.ahmed@linux.dev>
Use the new object read/write APIs instead of mapping APIs.
On compress side, zpool_obj_write() is more concise and provides exactly
what zswap needs to write the compressed object to the zpool, instead of
map->copy->unmap.
On the decompress side, zpool_obj_read_begin() is sleepable, which
allows avoiding the memcpy() for zsmalloc and slightly simplifying the
code by:
- Avoiding checking if the zpool driver is sleepable, reducing special
cases and shrinking the huge comment.
- Having a single zpool_obj_read_end() call rather than multiple
conditional zpool_unmap_handle() calls.
The !virt_addr_valid() case can be removed in the future if the crypto
API supports kmap addresses or by using kmap_to_page(), completely
eliminating the memcpy() path in zswap_decompress(). This a step toward
that. In that spirit, opportunistically make the comment more specific
about the kmap case instead of generic non-linear addresses. This is the
only case that needs to be handled in practice, and the generic comment
makes it seem like a bigger problem that it actually is.
Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
---
Herbert, I think we can completely get rid of the memcpy() in
zswap_decompress() if we can pass a highmem address to sg and crypto. I
believe your new virtual address API may be used here for this?
---
mm/zswap.c | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index 10f2a16e75869..4c474b692828d 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -930,7 +930,6 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry,
unsigned int dlen = PAGE_SIZE;
unsigned long handle;
struct zpool *zpool;
- char *buf;
gfp_t gfp;
u8 *dst;
@@ -972,10 +971,7 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry,
if (alloc_ret)
goto unlock;
- buf = zpool_map_handle(zpool, handle, ZPOOL_MM_WO);
- memcpy(buf, dst, dlen);
- zpool_unmap_handle(zpool, handle);
-
+ zpool_obj_write(zpool, handle, dst, dlen);
entry->handle = handle;
entry->length = dlen;
@@ -996,24 +992,22 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio)
struct zpool *zpool = entry->pool->zpool;
struct scatterlist input, output;
struct crypto_acomp_ctx *acomp_ctx;
- u8 *src;
+ u8 *src, *obj;
acomp_ctx = acomp_ctx_get_cpu_lock(entry->pool);
- src = zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO);
+ obj = zpool_obj_read_begin(zpool, entry->handle, acomp_ctx->buffer);
+
/*
- * 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.
+ * zpool_obj_read_begin() might return a kmap address of highmem when
+ * acomp_ctx->buffer is not used. However, sg_init_one() does not
+ * handle highmem addresses, so copy the object to acomp_ctx->buffer.
*/
- if ((acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) ||
- !virt_addr_valid(src)) {
- memcpy(acomp_ctx->buffer, src, entry->length);
+ if (virt_addr_valid(obj)) {
+ src = obj;
+ } else {
+ WARN_ON_ONCE(obj == acomp_ctx->buffer);
+ memcpy(acomp_ctx->buffer, obj, entry->length);
src = acomp_ctx->buffer;
- zpool_unmap_handle(zpool, entry->handle);
}
sg_init_one(&input, src, entry->length);
@@ -1023,8 +1017,7 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio)
BUG_ON(crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_ctx->wait));
BUG_ON(acomp_ctx->req->dlen != PAGE_SIZE);
- if (src != acomp_ctx->buffer)
- zpool_unmap_handle(zpool, entry->handle);
+ zpool_obj_read_end(zpool, entry->handle, obj);
acomp_ctx_put_unlock(acomp_ctx);
}
--
2.48.1.711.g2feabab25a-goog
next prev parent reply other threads:[~2025-03-05 6:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 6:11 [PATCH mm-unstable 0/5] Switch zswap to object read/write APIs Yosry Ahmed
2025-03-05 6:11 ` [PATCH mm-unstable 1/5] mm: zpool: Add interfaces for " Yosry Ahmed
2025-03-05 8:18 ` Sergey Senozhatsky
2025-03-05 14:43 ` Johannes Weiner
2025-03-05 17:32 ` Nhat Pham
2025-03-05 6:11 ` Yosry Ahmed [this message]
2025-03-05 14:48 ` [PATCH mm-unstable 2/5] mm: zswap: Use object read/write APIs instead of object mapping APIs Johannes Weiner
2025-03-05 17:35 ` Nhat Pham
2025-03-05 6:11 ` [PATCH mm-unstable 3/5] mm: zpool: Remove " Yosry Ahmed
2025-03-05 8:17 ` Sergey Senozhatsky
2025-03-05 14:49 ` Johannes Weiner
2025-03-05 17:37 ` Nhat Pham
2025-03-06 1:48 ` Herbert Xu
2025-03-06 4:19 ` Herbert Xu
2025-03-06 16:55 ` Yosry Ahmed
2025-03-07 2:38 ` Herbert Xu
2025-03-07 5:19 ` Sergey Senozhatsky
2025-03-06 14:15 ` Johannes Weiner
2025-03-05 6:11 ` [PATCH mm-unstable 4/5] mm: zsmalloc: Remove object mapping APIs and per-CPU map areas Yosry Ahmed
2025-03-05 8:16 ` Sergey Senozhatsky
2025-03-05 14:51 ` Johannes Weiner
2025-03-05 17:39 ` Nhat Pham
2025-03-05 18:57 ` Yosry Ahmed
2025-03-05 6:11 ` [PATCH mm-unstable 5/5] mm: zpool: Remove zpool_malloc_support_movable() Yosry Ahmed
2025-03-05 8:14 ` Sergey Senozhatsky
2025-03-05 14:53 ` Johannes Weiner
2025-03-05 17:05 ` Nhat Pham
2025-03-05 8:18 ` [PATCH mm-unstable 0/5] Switch zswap to object read/write APIs Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250305061134.4105762-3-yosry.ahmed@linux.dev \
--to=yosry.ahmed@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=hannes@cmpxchg.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=nphamcs@gmail.com \
--cc=peterz@infradead.org \
--cc=senozhatsky@chromium.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®