On Fri, May 17 2013, Jens Axboe wrote: > On Fri, May 17 2013, Jens Axboe wrote: > > On Fri, May 17 2013, Edoardo Comar wrote: > > > Hi Jens, > > > > > > thanks a lot, I tried your suggestion straight away: > > > The cpu line in the output shows that the job has not been idle at all. > > > but even with thinktime_spin, the latency stays high at at 150ms. > > > > > > Note also that if I increase thinktime & thinktime_spin by another 10000 > > > us > > > to a total of 20000, then the reported latency goes up another 150ms to a > > > total of 300ms. > > > Could this be a bug? > > > > It certainly could. Let me take a look here and see if I can reproduce > > it. > > And it was... Basically the same issue that was fixed for rate limiting. > When going to sleep or spinning, ensure that we have all IOs flushed. > Otherwise we could unfairly attribute the sleep towards the completion > latencies. > > Fixed here: > > http://git.kernel.dk/?p=fio.git;a=commit;h=002e7183cb86d6100efef690b6fa90bf0988b084 > > or just git pull and you'll get the fix. Also note this: http://git.kernel.dk/?p=fio.git;a=commit;h=4d01ece69f7b4d7bd56210e0f839944a91c5679f which explains how thinktime_blocks will effectively reduce iodepth=, if the former is smaller. So if you want a larger queue depth with thinktime being set, consider setting thinktime_blocks= to only wait every X blocks instead. Or keep it at 1, but do realize that this then caps your effective device queue depth to 1. -- 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
