From: Jens Axboe <axboe@kernel.dk>
To: Omar Sandoval <osandov@osandov.com>
Cc: sbates@raithlin.com, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, Damien.LeMoal@wdc.com,
sagi@grimberg.me
Subject: Re: [PATCH v3 2/2] blk-mq: Add a polling specific stats function
Date: Thu, 20 Apr 2017 14:22:23 -0600 [thread overview]
Message-ID: <808e7f83-9f55-29cf-7472-c09daea665bd@kernel.dk> (raw)
In-Reply-To: <20170420202039.GB24823@vader.DHCP.thefacebook.com>
On 04/20/2017 02:20 PM, Omar Sandoval wrote:
> On Thu, Apr 20, 2017 at 02:16:04PM -0600, Jens Axboe wrote:
>> On 04/20/2017 02:07 PM, Omar Sandoval wrote:
>>> On Fri, Apr 07, 2017 at 06:24:03AM -0600, sbates@raithlin.com wrote:
>>>> From: Stephen Bates <sbates@raithlin.com>
>>>>
>>>> Rather than bucketing IO statisics based on direction only we also
>>>> bucket based on the IO size. This leads to improved polling
>>>> performance. Update the bucket callback function and use it in the
>>>> polling latency estimation.
>>>>
>>>> Signed-off-by: Stephen Bates <sbates@raithlin.com>
>>>
>>> Hey, Stephen, just taking a look at this now. Comments below.
>>>
>>>> ---
>>>> block/blk-mq.c | 45 +++++++++++++++++++++++++++++++++++----------
>>>> 1 file changed, 35 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/block/blk-mq.c b/block/blk-mq.c
>>>> index 061fc2c..5fd376b 100644
>>>> --- a/block/blk-mq.c
>>>> +++ b/block/blk-mq.c
>>>> @@ -42,6 +42,25 @@ static LIST_HEAD(all_q_list);
>>>> static void blk_mq_poll_stats_start(struct request_queue *q);
>>>> static void blk_mq_poll_stats_fn(struct blk_stat_callback *cb);
>>>>
>>>> +/* Must be consisitent with function below */
>>>> +#define BLK_MQ_POLL_STATS_BKTS 16
>>>> +static int blk_mq_poll_stats_bkt(const struct request *rq)
>>>> +{
>>>> + int ddir, bytes, bucket;
>>>> +
>>>> + ddir = blk_stat_rq_ddir(rq);
>>>
>>> No need to call the wrapper function here, we can use rq_data_dir()
>>> directly.
>>>
>>>> + bytes = blk_rq_bytes(rq);
>>>> +
>>>> + bucket = ddir + 2*(ilog2(bytes) - 9);
>>>> +
>>>> + if (bucket < 0)
>>>> + return -1;
>>>> + else if (bucket >= BLK_MQ_POLL_STATS_BKTS)
>>>> + return ddir + BLK_MQ_POLL_STATS_BKTS - 2;
>>>> +
>>>> + return bucket;
>>>> +}
>>>
>>> Nitpicking here, but defining things in terms of the number of size
>>> buckets seems more natural to me. How about something like this
>>> (untested)? Note that this obviates the need for patch 1.
>>>
>>> #define BLK_MQ_POLL_STATS_SIZE_BKTS 8
>>> static unsigned int blk_mq_poll_stats_bkt(const struct request *rq)
>>> {
>>> unsigned int size_bucket;
>>>
>>> size_bucket = clamp(ilog2(blk_rq_bytes(rq)) - 9, 0,
>>> BLK_MQ_POLL_STATS_SIZE_BKTS - 1);
>>> return 2 * size_bucket + rq_data_dir(rq);
>>> }
>>
>> As I wrote in an earlier reply, it would be a lot cleaner to just have
>> the buckets be:
>>
>> buckets[2][BUCKETS_PER_RW];
>>
>> and not have to do weird math based on both size and data direction.
>> Just have it return the bucket index based on size, and have the caller
>> do:
>>
>> bucket[rq_data_dir(rq)][bucket_index];
>
> This removes a lot of the flexibility of the interface. Kyber, for one,
> has this stats callback:
>
> static unsigned int rq_sched_domain(const struct request *rq)
> {
> unsigned int op = rq->cmd_flags;
>
> if ((op & REQ_OP_MASK) == REQ_OP_READ)
> return KYBER_READ;
> else if ((op & REQ_OP_MASK) == REQ_OP_WRITE && op_is_sync(op))
> return KYBER_SYNC_WRITE;
> else
> return KYBER_OTHER;
> }
Good point, I guess other users could have different methods of bucketization.
> The buckets aren't subdivisions of read vs. write. We could shoehorn it
> in your way if we really wanted to, but that's pointless.
Nah, let's just leave it as-is then, even though I don't think it's the
prettiest thing I've ever seen.
--
Jens Axboe
next prev parent reply other threads:[~2017-04-20 20:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 12:24 [PATCH v3 0/2] blk-stat: Add ability to not bucket IO; improve IO polling sbates
2017-04-07 12:24 ` [PATCH v3 1/2] blk-stat: convert blk-stat bucket callback to signed sbates
2017-04-07 12:24 ` [PATCH v3 2/2] blk-mq: Add a polling specific stats function sbates
2017-04-20 20:07 ` Omar Sandoval
2017-04-20 20:16 ` Jens Axboe
2017-04-20 20:20 ` Omar Sandoval
2017-04-20 20:22 ` Jens Axboe [this message]
2017-04-20 20:33 ` Stephen Bates
2017-04-20 20:34 ` Jens Axboe
2017-04-20 20:47 ` Stephen Bates
2017-04-20 20:53 ` Jens Axboe
2017-04-20 21:08 ` Stephen Bates
2017-04-20 21:14 ` Jens Axboe
2017-04-20 21:41 ` Stephen Bates
2017-04-20 21:42 ` Jens Axboe
2017-04-20 21:45 ` Stephen Bates
2017-04-20 22:05 ` Stephen Bates
2017-04-20 22:06 ` Jens Axboe
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=808e7f83-9f55-29cf-7472-c09daea665bd@kernel.dk \
--to=axboe@kernel.dk \
--cc=Damien.LeMoal@wdc.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=osandov@osandov.com \
--cc=sagi@grimberg.me \
--cc=sbates@raithlin.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