On 03/03/2016 09:37 PM, Vladislav Bolkhovitin wrote:
Jens Axboe wrote on 03/03/2016 08:20 AM:
On Thu, Mar 03 2016, Sitsofe Wheeler wrote:
On 3 March 2016 at 03:03, Vladislav Bolkhovitin <vst@xxxxxxxx> wrote:
For those who asked about perf profiling, it remained the same as before with the CPU
consumption is all about timekeeping and memset:
- 55.74% fio fio [.] clock_thread_fn
clock_thread_fn
Perhaps this is what is already included above but could you use the
-g option on perf to collect it into a call-graph and post the top
results?
The above looks like a side effect of using gtod_cpu, it'll burn one
core. For the original poster - did you verify whether using gtod_cpu
was faster than using the CPU clock source in each CPU?
Yes, I had verified it and mentioned in one of my reports. It slightly decreased the
IOPS. I guess, it's a locking contention somewhere.
For clocksource=cpu there is no internal fio contention, nor can there
be any kernel/OS contention. Getting the clock is serializing, so that
might slow things down a bit.
I've seen you bring up this contention idea before. Is that pure
guesswork on your end, or have you profiled any contention? For most fio
workloads there is no cross-job traffic, that's by design. Fio does add
some overhead in general (everything does), and some of it is opt-out
like cutting down on the number of time calls (gtod_cpu). But that's
different from any locking contention between jobs, since it's constant
and isn't affected by how you spread the workloads.
--
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
