From: Jens Axboe <axboe@kernel.dk>
To: linux-block@vger.kernel.org
Cc: kbusch@kernel.org, joshi.k@samsung.com
Subject: Re: [PATCHSET RFC v2 0/5] Cache issue side time querying
Date: Tue, 16 Jan 2024 14:08:36 -0700 [thread overview]
Message-ID: <a43fda39-cda6-4fa4-9c5a-2062b0ef19f8@kernel.dk> (raw)
In-Reply-To: <20240116165814.236767-1-axboe@kernel.dk>
On 1/16/24 9:54 AM, Jens Axboe wrote:
> Results in patch 2, but tldr is a more than 9% improvement (108M -> 118M
> IOPS) for my test case, which doesn't even enable most of the costly
> block layer items that you'd typically find in a distro and which would
> further increase the number of issue side time calls. This brings iostats
> enabled _almost_ to the level of turning it off.
Enabled the typical distro things (block cgroups, blk-wbt, iocost,
iolatency) which all add considerable cost (and is an optimization
project in itself) and this is the performance of the stock kernel with
iostats enabled:
IOPS=91.01M, BW=44.44GiB/s, IOS/call=32/32
IOPS=91.29M, BW=44.58GiB/s, IOS/call=31/32
IOPS=91.27M, BW=44.57GiB/s, IOS/call=32/31
IOPS=91.26M, BW=44.56GiB/s, IOS/call=32/31
IOPS=91.38M, BW=44.62GiB/s, IOS/call=32/31
IOPS=91.28M, BW=44.57GiB/s, IOS/call=32/32
which is down from 122M for an optimized config and with iostats off.
With this patchset applied (and one extra patch, missed a spot...), we
now get:
IOPS=101.38M, BW=49.50GiB/s, IOS/call=32/32
IOPS=101.31M, BW=49.47GiB/s, IOS/call=32/32
IOPS=101.35M, BW=49.49GiB/s, IOS/call=31/31
IOPS=101.44M, BW=49.53GiB/s, IOS/call=32/31
IOPS=101.32M, BW=49.47GiB/s, IOS/call=32/32
IOPS=101.14M, BW=49.38GiB/s, IOS/call=32/31
which is about a 10% improvement. Mostly ran this because I was curious,
and while the above config changes do add more time stamping, it also
adds additional overhead. In any case, 10% win for the distro config
case is not bad at all.
--
Jens Axboe
prev parent reply other threads:[~2024-01-16 21:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 16:54 [PATCHSET RFC v2 0/5] Cache issue side time querying Jens Axboe
2024-01-16 16:54 ` [PATCH 1/5] block: add blk_time_get_ns() helper Jens Axboe
2024-01-17 8:01 ` Johannes Thumshirn
2024-01-16 16:54 ` [PATCH 2/5] block: cache current nsec time in struct blk_plug Jens Axboe
2024-01-17 8:02 ` Johannes Thumshirn
2024-01-16 16:54 ` [PATCH 3/5] block: update cached timestamp post schedule/preemption Jens Axboe
2024-01-17 8:06 ` Johannes Thumshirn
2024-01-16 16:54 ` [PATCH 4/5] block: shrink plug->{nr_ios, rq_count} to unsigned char Jens Axboe
2024-01-16 16:54 ` [PATCH 5/5] block: convert struct blk_plug callback list to hlists Jens Axboe
2024-01-16 17:03 ` Jens Axboe
2024-01-16 21:08 ` Jens Axboe [this message]
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=a43fda39-cda6-4fa4-9c5a-2062b0ef19f8@kernel.dk \
--to=axboe@kernel.dk \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.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