From: Jens Axboe <axboe@kernel.dk>
To: Brian King <brking@linux.vnet.ibm.com>, linux-block@vger.kernel.org
Cc: dm-devel@redhat.com, snitzer@redhat.com, agk@redhat.com
Subject: Re: [PATCH 1/1] block: Convert hd_struct in_flight from atomic to percpu
Date: Wed, 28 Jun 2017 15:49:52 -0600 [thread overview]
Message-ID: <c91629be-26db-96bb-9a55-18a6861888b2@kernel.dk> (raw)
In-Reply-To: <20170628211010.4C8C9124035@b01ledav002.gho.pok.ibm.com>
On 06/28/2017 03:12 PM, Brian King wrote:
> This patch converts the in_flight counter in struct hd_struct from a
> pair of atomics to a pair of percpu counters. This eliminates a couple
> of atomics from the hot path. When running this on a Power system, to
> a single null_blk device with 80 submission queues, irq mode 0, with
> 80 fio jobs, I saw IOPs go from 1.5M IO/s to 11.4 IO/s.
This has been done before, but I've never really liked it. The reason is
that it means that reading the part stat inflight count now has to
iterate over every possible CPU. Did you use partitions in your testing?
How many CPUs were configured? When I last tested this a few years ago
on even a quad core nehalem (which is notoriously shitty for cross-node
latencies), it was a net loss.
I do agree that we should do something about it, and it's one of those
items I've highlighted in talks about blk-mq on pending issues to fix
up. It's just not great as it currently stands, but I don't think per
CPU counters is the right way to fix it, at least not for the inflight
counter.
--
Jens Axboe
next prev parent reply other threads:[~2017-06-28 21:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 21:12 [PATCH 1/1] block: Convert hd_struct in_flight from atomic to percpu Brian King
2017-06-28 21:49 ` Jens Axboe [this message]
2017-06-28 22:04 ` Brian King
2017-06-29 8:40 ` Ming Lei
2017-06-29 15:58 ` Jens Axboe
2017-06-29 16:00 ` Jens Axboe
2017-06-29 18:42 ` Jens Axboe
2017-06-30 1:20 ` Ming Lei
2017-06-30 2:17 ` Jens Axboe
2017-06-30 13:05 ` [dm-devel] " Brian King
2017-06-30 14:08 ` Jens Axboe
2017-06-30 18:33 ` Brian King
2017-06-30 23:23 ` Ming Lei
2017-06-30 23:26 ` Jens Axboe
2017-07-01 2:18 ` Brian King
2017-07-04 1:20 ` Ming Lei
2017-07-04 20:58 ` Brian King
2017-07-01 4:17 ` Jens Axboe
2017-07-01 4:59 ` Jens Axboe
2017-07-01 16:43 ` Jens Axboe
2017-07-04 20:55 ` Brian King
2017-07-04 21:57 ` Jens Axboe
2017-06-29 16:25 ` Ming Lei
2017-06-29 17:31 ` Brian King
2017-06-30 1:08 ` Ming Lei
2017-06-28 21:54 ` Jens Axboe
2017-06-28 21:59 ` Jens Axboe
2017-06-28 22:07 ` [dm-devel] " Brian King
2017-06-28 22:19 ` Jens Axboe
2017-06-29 12:59 ` Brian King
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=c91629be-26db-96bb-9a55-18a6861888b2@kernel.dk \
--to=axboe@kernel.dk \
--cc=agk@redhat.com \
--cc=brking@linux.vnet.ibm.com \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=snitzer@redhat.com \
/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