linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCHv3 00/11] zram: preemptible writes and occasionally preemptible reads
@ 2025-01-30 11:10 Sergey Senozhatsky
  2025-01-30 11:10 ` [PATCHv3 01/11] zram: switch to non-atomic entry locking Sergey Senozhatsky
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: Sergey Senozhatsky @ 2025-01-30 11:10 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Minchan Kim, linux-mm, linux-kernel, Sergey Senozhatsky

This is Part I which only changes zram.  In order to make reads()
preemptible we also need Part II [1] which changes zsmalloc.

There are more details in the commit messages, but in short:

Currently zram runs compression and decompression in non-preemptible
sections, e.g.

    zcomp_stream_get()     // grabs CPU local lock
    zcomp_compress()

or

    zram_slot_lock()       // grabs entry spin-lock
    zcomp_stream_get()     // grabs CPU local lock
    zs_map_object()        // grabs rwlock and CPU local lock
    zcomp_decompress()

Potentially a little troublesome for a number of reasons.

For instance, this makes it impossible to use async compression
algorithms or/and H/W compression algorithms, which can wait for OP
completion or resource availability.  This also restricts what
compression algorithms can do internally, for example, zstd can
allocate internal state memory for C/D dictionaries:

do_fsync()
 do_writepages()
  zram_bio_write()
   zram_write_page()                          // become non-preemptible
    zcomp_compress()
     zstd_compress()
      ZSTD_compress_usingCDict()
       ZSTD_compressBegin_usingCDict_internal()
        ZSTD_resetCCtx_usingCDict()
         ZSTD_resetCCtx_internal()
          zstd_custom_alloc()                 // memory allocation

Not to mention that the system can be configured to maximize
compression ratio at a cost of CPU/HW time (e.g. lz4hc or deflate
with very high compression level) so zram can stay in non-preemptible
section (even under spin-lock or/and rwlock) for an extended period
of time.  Aside from compression algorithms, this also restricts what
zram can do.  One particular example is zram_write_page() zsmalloc
handle allocation, which has an optimistic allocation (disallowing
direct reclaim) and a pessimistic fallback path, which then forces
zram to compress the page one more time.

This series changes zram to not directly impose atomicity restrictions
on compression algorithms (and on itself), which makes zram write()
fully preemptible; zram read(), sadly, is not always preemptible.  There
are still indirect atomicity restrictions imposed by zsmalloc().  Changing
zsmalloc to permit preemption under zs_map_object() is a separate effort
(Part II [1]) and will be posted shortly.

[1] https://lore.kernel.org/linux-mm/20250130044455.2642465-1-senozhatsky@chromium.org

v2 -> v3:
- Fixed a potential double stream-put during recompression (Dan Carpenter)
- Added a patch to filter out recompression slots by compression priority
- Tweaked cmpxchg loops (based on similar zsmalloc feedback from Uros
  Bizjak)
- Added some more sanity checks to recompression

Sergey Senozhatsky (11):
  zram: switch to non-atomic entry locking
  zram: do not use per-CPU compression streams
  zram: remove crypto include
  zram: remove max_comp_streams device attr
  zram: remove two-staged handle allocation
  zram: permit reclaim in zstd custom allocator
  zram: permit reclaim in recompression handle allocation
  zram: remove writestall zram_stats member
  zram: limit max recompress prio to num_active_comps
  zram: filter out recomp targets based on priority
  zram: unlock slot during recompression

 Documentation/ABI/testing/sysfs-block-zram  |   8 -
 Documentation/admin-guide/blockdev/zram.rst |  36 +-
 drivers/block/zram/backend_zstd.c           |  11 +-
 drivers/block/zram/zcomp.c                  | 165 +++++----
 drivers/block/zram/zcomp.h                  |  17 +-
 drivers/block/zram/zram_drv.c               | 353 ++++++++++----------
 drivers/block/zram/zram_drv.h               |   9 +-
 include/linux/cpuhotplug.h                  |   1 -
 8 files changed, 283 insertions(+), 317 deletions(-)

-- 
2.48.1.262.g85cc9f2d1e-goog



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2025-01-30 14:19 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-30 11:10 [PATCHv3 00/11] zram: preemptible writes and occasionally preemptible reads Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 01/11] zram: switch to non-atomic entry locking Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 02/11] zram: do not use per-CPU compression streams Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 03/11] zram: remove crypto include Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 04/11] zram: remove max_comp_streams device attr Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 05/11] zram: remove two-staged handle allocation Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 06/11] zram: permit reclaim in zstd custom allocator Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 07/11] zram: permit reclaim in recompression handle allocation Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 08/11] zram: remove writestall zram_stats member Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 09/11] zram: limit max recompress prio to num_active_comps Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 10/11] zram: filter out recomp targets based on priority Sergey Senozhatsky
2025-01-30 11:10 ` [PATCHv3 11/11] zram: unlock slot during recompression Sergey Senozhatsky
2025-01-30 14:18 ` [PATCHv3 00/11] zram: preemptible writes and occasionally preemptible reads Sergey Senozhatsky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox