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.
--
Andrey Kudryavtsev,
SSD Solution Architect
Intel Corp.
inet: 83564353
work: +1-916-356-4353
mobile: +1-916-221-2281
On 2/21/15, 1:20 AM, "Sitsofe Wheeler" <[email protected]> wrote:
>On 20 February 2015 at 23:10, Kudryavtsev, Andrey O
><[email protected]> wrote:
>> I’m running NVMe SSD benchmarks which are using multi-job
>>configurations in the most common scenarios.
>> I have noticed that since 2.2.5 release FIO has 3-4 times higher CPU
>>utilization on the same workload, same system, same kernel 3.18.
>> In fact I’m not able to achieve 450k IOPS on latest Core-i7 CPU due to
>>100% utilization.
>> I tracked down the changes back, 2.1.14 is the most stable for me.
>>Release had 2.2.0 the reporting issues, which were fixed in 2.2.5 but
>>introduced high CPU utilization instead.
>> Did anyone notice that too?
>
>Where is the CPU usage going - userspace, device interrupts etc? If
>it's vanishing into userspace does gtod_reduce=1 make any difference?
>Does iostat confirm that you were getting more IOPs with the older
>fio? What's the maximum number of requests reported by
>/sys/block/<blockdevice>/queue/nr_requests ?
>
>(PS buffered=0 and direct=1 are synonyms of each other and why runtime=0?)
>
>--
>Sitsofe | http://sucs.org/~sits/
--
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
