On 03/09/2015 04:07 PM, Kudryavtsev, Andrey O wrote:
Thank you for the advise,
Utilization is coming from fio threads, reported I/O is similar to iostat.
Disabling all latency reporting works and returns the CPU utilization back
to normal. Unfortunately this workaround doesn’t work for me, I’m using
latency monitoring a lot for my tests.
I did some more research,
With latency reporting enabled I’m getеing 350k IOPS instead of 450k.
With gdot_disable=1 back to normal 450k
With disable_slat=1 only it gets 420k
disable_clat=1 doesn’t make any difference and the performace is still
low 350k.
Please, advise.
Please run a git bisect, as suggested. This will help pinpoint what
commit made it worse for you. Should be pretty easy to do, since you can
reproduce quickly and easily. You mentioned that 2.1.14 works, and that
2.2.5 is broken. So do:
$ git bisect start
$ git bisect good fio-2.1.14
$ git bisect bad fio-2.2.5
Now for each iteration, do:
$ make clean && make -j20
$ ./fio <jobfile>
if the result is slow, do:
$ git bisect bad
and if the result is fast, do:
$ git bisect good
Then go back to the make clean && make and rerun your test case. Repeat
this until you've bisected your way to the problematic commit, git will
tell you when it's done.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
