All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladislav Bolkhovitin <vst@vlnb.net>
To: Sitsofe Wheeler <sitsofe@gmail.com>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: Fio high IOPS measurement mistake
Date: Wed, 02 Mar 2016 19:02:37 -0800	[thread overview]
Message-ID: <56D7A94D.1010708@vlnb.net> (raw)
In-Reply-To: <CALjAwxgT1OHUWfx6p3=SZ=SnM2KyPTEs6xdMnb2dYjbzzq+zhA@mail.gmail.com>

Sitsofe Wheeler wrote on 03/01/2016 11:38 PM:
> On 2 March 2016 at 04:25, Vladislav Bolkhovitin <vst@vlnb.net> wrote:
>> Hi,
>>
>> Sitsofe Wheeler wrote on 02/29/2016 10:01 PM:
>>> Hi,
>>>
>>> On 1 March 2016 at 05:17, Vladislav Bolkhovitin <vst@vlnb.net> wrote:
>>>> Hello,
>>>>
>>>> I'm currently looking at one NVRAM device, and during fio tests noticed that each fio
>>>> thread consumes 30% of user space CPU. I'm using ioengine=libaio, buffered=0, sync=0
>>>> and direct=1, so user space CPU consumption should be virtually zero.
>>>>
>>>> That 30% user CPU consumption makes me suspect that this is overhead for internal fio
>>>> housekeeping, i.e., scientifically speaking, fio instrumental measurement mistake (I
>>>> hope, I'm using correct English terms).
>>>>
>>>> Can anybody comment it and suggest how to decrease this user space CPU consumption?
>>>>
>>>> Here is my full fio job:
>>>>
>>>> [global]
>>>> ioengine=libaio
>>>> buffered=0
>>>> sync=0
>>>> direct=1
>>>> randrepeat=1
>>>> softrandommap=1
>>>> rw=randread
>>>> bs=4k
>>>> filename=./nvram (it's a link to a block device)
>>>> exitall=1
>>>> thread=1
>>>> disable_lat=1
>>>> disable_slat=1
>>>> disable_clat=1
>>>> loops=10
>>>> iodepth=16
>>>
>>> You appear to be missing gtod_reduce
>>> (https://github.com/axboe/fio/blob/fio-2.6/HOWTO#L1668 ) or
>>> gettimeofday cpu pinning. You also aren't using batching
>>> (https://github.com/axboe/fio/blob/fio-2.6/HOWTO#L815 ).
>>
>> Thanks, I tried them, but they did not make any significant difference. The biggest
> 
> There was no cpu reduction from setting both iodepth_batch and
> iodepth_batch_complete together?

No, no significant difference.

I also forgot to mention that I had tried gtod_cpu=11 as well, and it only made things
worse.

>> difference I had was when I changed CPU governor to "performance". Now I have 20-25%
>> user space, measured by fio itself, it's coherent with top. Note, I'm considering
>> per-thread CPU consumption, to see it in top you need to press '1' (one line per each CPU).
> 
> Have you applied the points mentioned in
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Performance_Tuning_Guide/chap-Red_Hat_Enterprise_Linux-Performance_Tuning_Guide-Performance_Features_in_RednbspHat_EnterprisenbspLinuxnbsp7.html
> ? Things like the scheduler granularity (as changed by Red Hat's
> tuned-adm) can have a large impact...

Thanks for your help and feedback, but you are trying to improve my results, while I'm
asking how to _decrease fio overhead_ on high IOPS with libaio. It's very different
question.

>> The full job file was:
>>
>> [global]
>> ioengine=sync
>> buffered=0
>> sync=0
>> direct=1
> [...]
>> iodepth=8 /* does not matter */
> ^^^ It's worth noting that direct and iodepth don't really have an
> impact on synchronous ioengines -
> https://github.com/axboe/fio/blob/master/HOWTO#L804

Yes, sure, this is why I commented it as "doesn't matter".

Thanks,
Vlad

  reply	other threads:[~2016-03-03  3:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01  5:17 Fio high IOPS measurement mistake Vladislav Bolkhovitin
2016-03-01  6:01 ` Sitsofe Wheeler
2016-03-02  4:25   ` Vladislav Bolkhovitin
2016-03-02  7:38     ` Sitsofe Wheeler
2016-03-03  3:02       ` Vladislav Bolkhovitin [this message]
2016-03-02 18:37     ` Elliott, Robert (Persistent Memory)
2016-03-03  3:03       ` Vladislav Bolkhovitin
2016-03-03 21:03         ` Elliott, Robert (Persistent Memory)
2016-03-04  4:36           ` Vladislav Bolkhovitin
2016-03-03  3:03     ` Vladislav Bolkhovitin
2016-03-03  7:10       ` Sitsofe Wheeler
2016-03-03  7:13         ` Sitsofe Wheeler
2016-03-04  4:37           ` Vladislav Bolkhovitin
2016-03-03 16:20         ` Jens Axboe
2016-03-04  4:37           ` Vladislav Bolkhovitin
2016-03-04 15:33             ` Jens Axboe
2016-03-05  0:47               ` Vladislav Bolkhovitin
2016-03-05  0:54                 ` Jens Axboe
2016-03-05  1:09                   ` Vladislav Bolkhovitin
2016-03-04  4:37         ` Vladislav Bolkhovitin
2016-03-02  8:26 ` Andrey Kuzmin
2016-03-03  3:02   ` Vladislav Bolkhovitin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D7A94D.1010708@vlnb.net \
    --to=vst@vlnb.net \
    --cc=fio@vger.kernel.org \
    --cc=sitsofe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.