[PATCH 2/2] blk-stat: add a poll_size value to the request_queue struct

Stephen Bates sbates at raithlin.com
Tue Mar 28 14:52:57 PDT 2017


[Retrying as my new setup secretly converted to html format without telling me. Apologies for the resend.]

>>> 
>>> Thanks for the review Sagi. I’d be OK going with <=0 as the exact
>>> match would normally be for minimal IO sizes (where <= and = are the
>>> same thing). I will see what other feedback I get and aim to do a
>>> respin soon…
>> 
>> No tunables for this, please. There's absolutely no reason why we should
>> need it.
>
> Jens – by this you mean you want to only bucket IO that are exactly
> the minimum block size supported by the underlying block device? I was
> envisioning we might want to relax that in certain cases (e.g. bucket
> 4KB and below going to a 512B device).
 
> Sorry, the above was a bit terse. I think a much better solution would
> be to create a number of buckets (per data direction) and do stats on
> all of them. The buckets would cover a reasonable range of request
> sizes. Then when you poll for a given request, we can base our timed
> number on the data direction AND size of it. You can get pretty far with
> a few buckets:
> 
> 512b
> 4k
> 8k
> 16k
> 32k
> 64k
> 128k
> 
> and you could even have your time estimation function turn these into
> something sane. Or just use a composite of buckets, if you wish.
 
I did go down this path initially but then moved away from it since we were focusing only on the smaller IO size. However I can definitely take a look at this again as I agree that it could be more useful in the long run.
 
I would like to keep my first patch in this series alive since I do think having the option to not bucket an IO is a useful thing to have.
 
I’ll take all the feedback to date and work on a v2. Thanks!
 
Stephen





More information about the Linux-nvme mailing list