| Message ID | 20250129064853.2210753-1-senozhatsky@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | zsmalloc: preemptible object mapping | expand |
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 >
On (25/01/29 15:53), Yosry Ahmed wrote: > 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 Yeah I'm just messing around :)