All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Hillf Danton <hdanton@sina.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Brian Geffon <bgeffon@google.com>,
	linux-kernel@vger.kernel.org,  linux-block@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v6 09/13] zram: split zcomp into separate R/W streams
Date: Wed, 21 Oct 2026 13:56:17 +0900	[thread overview]
Message-ID: <athFf0kXopUKh2-V@google.com> (raw)
In-Reply-To: <20261021042350.907-1-hdanton@sina.com>

On (26/10/21 12:23), Hillf Danton wrote:
> On Wed, 21 Oct 2026 11:42:19 +0900 Sergey Senozhatsky wrote:
> > Split struct zcomp_strm into separate compression (Write zcomp_cstrm)
> > and decompression (Read zcomp_dstrm) streams, and split zcomp_ops
> > context creation/destruction into create_cctx/destroy_cctx and
> > optional create_dctx/destroy_dctx callbacks.
> > 
> > This decouples Read (decompression) and Write (compression) paths so
> > they no longer contend on the same per-CPU stream mutex (Writer vs
> > Reader priority inversion).  Currently, a (low priority) Writer that
> > holds the stream mutex can be preempted by a (higher priority) Reader
> > on the same CPU, which then blocks on that mutex until the Writer gets
> > to run again and releases it, which can take a long time when there
> > are other runnable tasks on that CPU.
> >
> Given lock like mutex, priority inversion happens from Monday to Friday,
> but I wonder if you are inventing some wheels in 2026 if proxy excution
> works for you.

Reader-Writer split is a foundation for further improvements (like
singleton recompression stream and so on).

  reply	other threads:[~2026-10-21  4:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21  2:42 [PATCH v6 00/13] zram: redesign zcomp and rework backends Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 01/13] zram: prefix backends printk-s Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 02/13] zram: remove debugfs entry on init failure Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 03/13] zram: reset writeback state in zram_reset_device() Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 04/13] zram: zstd: do not allocate empty C/D-dictionaries Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 05/13] zram: lz4hc: pre-initialize dictionary stream in setup_params Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 06/13] zram: lz4: use LZ4_decompress_safe_usingDict() Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 07/13] zram: lz4hc: " Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 08/13] zram: zstd: do not use kvzalloc() for zstd allocations Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 09/13] zram: split zcomp into separate R/W streams Sergey Senozhatsky
2026-10-21  4:23   ` Hillf Danton
2026-10-21  4:56     ` Sergey Senozhatsky [this message]
2026-10-21  7:53       ` Hillf Danton
2026-10-22  0:08         ` Hillf Danton
2026-10-22  0:19           ` Barry Song
2026-10-22 11:11             ` Hillf Danton
2026-10-23  5:01               ` Sergey Senozhatsky
2026-10-23 11:40                 ` Hillf Danton
2026-10-24  5:48                   ` Sergey Senozhatsky
2026-10-24 10:14                     ` Hillf Danton
2026-10-25  1:11                       ` Hillf Danton
2026-10-25  1:38                       ` Sergey Senozhatsky
2026-10-25 10:54                         ` Hillf Danton
2026-10-22  2:06           ` Sergey Senozhatsky
2026-10-22 23:25             ` Hillf Danton
2026-10-23  3:29               ` Sergey Senozhatsky
2026-10-23 17:05   ` Brian Geffon
2026-10-26  3:09     ` Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 10/13] zram: introduce shared decompression streams Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 11/13] zram: allocate bounce buffer for spanning objects Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 12/13] zram: borrow idle decompression streams in exclusive mode Sergey Senozhatsky
2026-10-21  2:42 ` [PATCH v6 13/13] zram: use a singleton compression context for recompression 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=athFf0kXopUKh2-V@google.com \
    --to=senozhatsky@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=bgeffon@google.com \
    --cc=hdanton@sina.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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.