From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Jihan LIN <linjh22s@gmail.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Minchan Kim <minchan@kernel.org>, Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
Kairui Song <kasong@tencent.com>
Subject: Re: [PATCH RFC v2 3/5] zram: Introduce zcomp-managed streams
Date: Wed, 11 Mar 2026 17:58:06 +0900 [thread overview]
Message-ID: <abEtQ6ULdxhBdkkG@google.com> (raw)
In-Reply-To: <CALmCz4rfM3graGfnrMjXwg+5W5gUrq2g0ycPwRbkcRKsL8woyw@mail.gmail.com>
Hi,
On (26/03/10 21:31), Jihan LIN wrote:
> Yes, the acomp crypto API can cover my user case. However, per-cpu
> streams can still limit concurrency to num_online_cpus() even with acomp
> as in mm/zswap.c. And simply replacing them with a global idle stream
> list leads to a significant lock contention regression, as tested by
> Kairui[1].
>
> Would it make sense to try using per-CPU stream first and fallback to a
> global idle stream pool only when the per-cpu stream is busy? Happy to
> help with the migration effort.
That's a good and difficult question. I was not planning on
re-introducing an idle list, wanted to keep things per-CPU,
the way they currently are. Hmm but our per-CPU model doesn't
fit at all. I don't have any good ideas now.
next prev parent reply other threads:[~2026-03-11 8:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 12:23 [PATCH RFC v2 0/5] zram: Allow zcomps to manage their own streams Jihan LIN
2026-03-09 12:23 ` Jihan LIN via B4 Relay
2026-03-09 12:23 ` [PATCH RFC v2 1/5] zram: Rename zcomp_strm_{init, free}() Jihan LIN
2026-03-09 12:23 ` Jihan LIN via B4 Relay
2026-03-09 12:23 ` [PATCH RFC v2 2/5] zram: Separate the lock from zcomp_strm Jihan LIN
2026-03-09 12:23 ` Jihan LIN via B4 Relay
2026-03-09 12:23 ` [PATCH RFC v2 3/5] zram: Introduce zcomp-managed streams Jihan LIN
2026-03-09 12:23 ` Jihan LIN via B4 Relay
2026-03-10 1:05 ` Sergey Senozhatsky
2026-03-10 13:31 ` Jihan LIN
2026-03-11 8:58 ` Sergey Senozhatsky [this message]
2026-03-09 12:23 ` [PATCH RFC v2 4/5] zram: Use zcomp-managed streams for async write requests Jihan LIN
2026-03-09 12:23 ` Jihan LIN via B4 Relay
2026-03-09 12:23 ` [PATCH RFC v2 5/5] zram: Add lz4 PoC for zcomp-managed streams Jihan LIN
2026-03-09 12:23 ` Jihan LIN via B4 Relay
2026-03-12 0:50 ` kernel test robot
2026-03-11 8:51 ` [PATCH RFC v2 0/5] zram: Allow zcomps to manage their own streams Sergey Senozhatsky
2026-03-13 14:42 ` Jihan LIN
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=abEtQ6ULdxhBdkkG@google.com \
--to=senozhatsky@chromium.org \
--cc=axboe@kernel.dk \
--cc=kasong@tencent.com \
--cc=linjh22s@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan@kernel.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.