lkml.org 
[lkml]   [2015]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [LKP] [block] 34b48db66e0: +3291.6% iostat.sde.wrqm/s
Date
Jens Axboe <axboe@fb.com> writes:

> On 01/22/2015 01:49 PM, Jeff Moyer wrote:
>> Jens Axboe <axboe@fb.com> writes:
>>
>>>> Agreed on all above, but are the actual benchmark numbers included
>>>> somewhere in all this mess? I'd like to see if the benchmark numbers
>>>> improved first, before digging into the guts of which functions are
>>>> called more or which stats changed.
>>>
>>> I deleted the original email, but the latter tables had drive throughput
>>> rates and it looked higher for the ones I checked on the newer kernel.
>>> Which the above math would indicate as well, multiplying reqs-per-sec
>>> and req-size.
>>
>> Looking back at the original[1], I think I see the throughput numbers for
>> iozone. The part that confused me was that each table mixes different
>> types of data. I'd much prefer if different data were put in different
>> tables, along with column headers that stated what was being reported
>> and the units for the measurements.
>>
>> Anyway, I find the increased service time troubling, especially this
>> one:
>>
>> testbox/testcase/testparams: ivb44/fsmark/performance-1x-1t-1HDD-xfs-4M-60G-NoSync
>>
>> 544 ? 0% +1268.9% 7460 ? 0% iostat.sda.w_await
>> 544 ? 0% +1268.5% 7457 ? 0% iostat.sda.await
>>
>> I'll add this to my queue of things to look into.
>
> From that same table:
>
> 1009 ± 0% +1255.7% 13682 ± 0% iostat.sda.avgrq-sz
>
> the average request size has gone up equally. This is clearly a streamed
> oriented benchmark, if the IOs get that big.

Hmm, ok, I'll buy that. However, I am surprised that the relationship
between i/o size and service time is 1:1 here...

Thanks!
Jeff


\
 
 \ /
  Last update: 2015-01-22 22:21    [W:0.074 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site