From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@infradead.org>,
"minchan@kernel.org" <minchan@kernel.org>,
"senozhatsky@chromium.org" <senozhatsky@chromium.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH 1/3] zram: allow user to set QUEUE_FLAG_NOWAIT
Date: Tue, 16 May 2023 22:08:50 +0900 [thread overview]
Message-ID: <20230516130850.GA298930@google.com> (raw)
In-Reply-To: <2e6864ef-394d-f43e-9175-a4f3da65c755@nvidia.com>
On (23/05/16 05:51), Chaitanya Kulkarni wrote:
> Removed modparam v2 is ready to send, but I've few concerns enabling
> nowait unconditionally for zram :-
>
> From brd data [1] and zram data [2] from my setup :-
>
> IOPs (old->new) | sys cpu% (old->new)
> --------------------------------------------------
> brd | 1.5x (3919 -> 5874) | 3x (29 -> 87)
> zram | 1.09x ( 29 -> 87) | 9x (11 -> 97)
>
> brd:-
> IOPs increased by ~1.5 times (50% up)
> sys CPU percentage increased by ~3.0 times (200% up)
>
> zram:-
> IOPs increased by ~1.09 times ( 9% up)
> sys CPU percentage increased by ~8.81 times (781% up)
>
> This comparison clearly demonstrates that zram experiences a much more
> substantial CPU load relative to the increase in IOPs compared to brd.
> Such a significant difference might suggest a potential CPU regression
> in zram ?
>
> Especially for zram, if applications are not expecting this high cpu
> usage then they we'll get regression reports with default nowait
> approach. How about we avoid something like this with one of the
> following options ?
Well, zram performs decompression/compression on the CPU (per-CPU
crypto streams) for each IO operation, so zram IO is CPU intensive.
next prev parent reply other threads:[~2023-05-16 13:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-12 8:29 [PATCH 0/3] zram: queue flag nowait and mior cleanup Chaitanya Kulkarni
2023-05-12 8:29 ` [PATCH 1/3] zram: allow user to set QUEUE_FLAG_NOWAIT Chaitanya Kulkarni
2023-05-12 14:31 ` Christoph Hellwig
2023-05-12 14:34 ` Jens Axboe
2023-05-13 1:06 ` Chaitanya Kulkarni
2023-05-16 5:51 ` Chaitanya Kulkarni
2023-05-16 13:08 ` Sergey Senozhatsky [this message]
2023-05-16 20:41 ` Chaitanya Kulkarni
2023-05-16 20:43 ` Jens Axboe
2023-05-16 21:32 ` Chaitanya Kulkarni
2023-05-16 22:03 ` Jens Axboe
2023-05-13 1:05 ` Chaitanya Kulkarni
2023-05-12 8:29 ` [PATCH 2/3] zram: consolidate zram_bio_read()_zram_bio_write() Chaitanya Kulkarni
2023-05-12 14:32 ` Christoph Hellwig
2023-05-13 1:06 ` Chaitanya Kulkarni
2023-05-12 8:29 ` [PATCH 3/3] zram: add flush_dcache_page() call for write Chaitanya Kulkarni
2023-05-12 14:34 ` Christoph Hellwig
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=20230516130850.GA298930@google.com \
--to=senozhatsky@chromium.org \
--cc=axboe@kernel.dk \
--cc=chaitanyak@nvidia.com \
--cc=hch@infradead.org \
--cc=linux-block@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).