Thank you, I’ll do that. -- Andrey Kudryavtsev, SSD Solution Architect Intel Corp. inet: 83564353 work: +1-916-356-4353 mobile: +1-916-221-2281
On 3/17/15, 4:16 PM, "Jens Axboe" <[email protected]> wrote: >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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
