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" <sitsofe@xxxxxxxxx> wrote: >On 20 February 2015 at 23:10, Kudryavtsev, Andrey O ><andrey.o.kudryavtsev@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
