All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosry.ahmed@linux.dev>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Nhat Pham <nphamcs@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv1 0/6] zsmalloc: preemptible object mapping
Date: Wed, 29 Jan 2025 15:53:49 +0000	[thread overview]
Message-ID: <Z5pPDV3Ub6EeWCxD@google.com> (raw)
In-Reply-To: <20250129064853.2210753-1-senozhatsky@chromium.org>

On Wed, Jan 29, 2025 at 03:43:46PM +0900, Sergey Senozhatsky wrote:
> This is Part II of the series [1] that makes zram read() and write()
> preemptible.  This part focuses only zsmalloc because zsmalloc imposes
> atomicity restrictions on its users.  One notable example is object
> mapping API, which returns with:
> a) local CPU lock held
> b) zspage rwlock held
> 
> First, zsmalloc is converted to use sleepable RW-"lock" (it's atomic_t
> in fact) for zspage migration protection.  Second, a new handle mapping
> is introduced which doesn't use per-CPU buffers (and hence no local CPU
> lock), does fewer memcpy() calls, but requires users to provide a
> pointer to temp buffer for object copy-in (when needed).  Third, zram is
> converted to the new zsmalloc mapping API and thus zram read() becomes
> preemptible.
> 
> [1] https://lore.kernel.org/linux-mm/20250127072932.1289973-1-senozhatsky@chromium.org
> 
> RFC -> v1:
> - Only zspage->lock (leaf-lock for zs_map_object()) is converted
>   to a preemptible lock.  The rest of the zspool locks remain the
>   same (Yosry hated with passion the fact that in RFC series all
>   zspool looks would become preemptible).

Hated is a big word here, I was merely concerned about how the locking
changes would affect performance :P

> - New zs object mapping API (Yosry hated RFC API with passion).
>   We know have obj_read_begin()/obj_read_end() and obj_write().
> - obj_write() saves extra memcpy() calls for objects that span two
>   physical pages.
> - Dropped zram deferred slot-free-notification handling (I hated
>   it with passion)
> 
> Sergey Senozhatsky (6):
>   zsmalloc: factor out pool locking helpers
>   zsmalloc: factor out size-class locking helpers
>   zsmalloc: make zspage lock preemptible
>   zsmalloc: introduce new object mapping API
>   zram: switch to new zsmalloc object mapping API
>   zram: add might_sleep to zcomp API
> 
>  drivers/block/zram/zcomp.c    |   6 +-
>  drivers/block/zram/zcomp.h    |   2 +
>  drivers/block/zram/zram_drv.c |  28 +--
>  include/linux/zsmalloc.h      |   8 +
>  mm/zsmalloc.c                 | 372 ++++++++++++++++++++++++++--------
>  5 files changed, 311 insertions(+), 105 deletions(-)
> 
> -- 
> 2.48.1.262.g85cc9f2d1e-goog
> 


  parent reply	other threads:[~2025-01-29 15:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-29  6:43 [PATCHv1 0/6] zsmalloc: preemptible object mapping Sergey Senozhatsky
2025-01-29  6:43 ` [PATCHv1 1/6] zsmalloc: factor out pool locking helpers Sergey Senozhatsky
2025-01-29 16:59   ` Yosry Ahmed
2025-01-30  4:01     ` Sergey Senozhatsky
2025-01-30 16:25       ` Yosry Ahmed
2025-01-31  3:34         ` Sergey Senozhatsky
2025-01-29  6:43 ` [PATCHv1 2/6] zsmalloc: factor out size-class " Sergey Senozhatsky
2025-01-29 17:01   ` Yosry Ahmed
2025-01-29  6:43 ` [PATCHv1 3/6] zsmalloc: make zspage lock preemptible Sergey Senozhatsky
2025-01-29 11:25   ` Sergey Senozhatsky
2025-01-29 15:22   ` Uros Bizjak
2025-01-30  3:22     ` Sergey Senozhatsky
2025-01-29  6:43 ` [PATCHv1 4/6] zsmalloc: introduce new object mapping API Sergey Senozhatsky
2025-01-29 17:31   ` Yosry Ahmed
2025-01-30  3:21     ` Sergey Senozhatsky
2025-01-30  4:17       ` Sergey Senozhatsky
2025-01-30 16:27       ` Yosry Ahmed
2025-01-29  6:43 ` [PATCHv1 5/6] zram: switch to new zsmalloc " Sergey Senozhatsky
2025-01-29  6:43 ` [PATCHv1 6/6] zram: add might_sleep to zcomp API Sergey Senozhatsky
2025-01-29 15:53 ` Yosry Ahmed [this message]
2025-01-30  3:13   ` [PATCHv1 0/6] zsmalloc: preemptible object mapping 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=Z5pPDV3Ub6EeWCxD@google.com \
    --to=yosry.ahmed@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=nphamcs@gmail.com \
    --cc=senozhatsky@chromium.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.