From: Vladislav Bolkhovitin <vst@vlnb.net>
To: "Elliott, Robert (Persistent Memory)" <elliott@hpe.com>,
Sitsofe Wheeler <sitsofe@gmail.com>,
"fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: Fio high IOPS measurement mistake
Date: Wed, 02 Mar 2016 19:03:00 -0800 [thread overview]
Message-ID: <56D7A964.3040809@vlnb.net> (raw)
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B40295C349408@G9W0745.americas.hpqcorp.net>
Elliott, Robert (Persistent Memory) wrote on 03/02/2016 10:37 AM:
>>>> 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 ).
>>
> ...
>> Jobs IOPS(M) %user %sys
>> 1 4.3 78 22
>> 2 7.6 67 33
>> 3 10.5 65 35
>> 4 7.7 61 38
>> 5 4.8 78 22
>> 6 4.7 83 17
>> 7 4.8 84 15
>
> Use cpus_allowed_policy=split to keep threads or processes
> from wandering across CPUs.
Tried, no help, which is easily explainable, because I'm always running num jobs < num
CPUs.
> If the system is NUMA, split the NVDIMMs based on that
> and use cpus_allowed to just have threads access local
> NVDIMMs.
No, it's single socket.
> As someone else mentioned, the random map overhead is
> noticeable, especially for large capacity devices. Use
> norandommap and randrepeat=0.
Had done, see the job file in my message you didn't quote.
> There was a problem in 2014 requiring invalidate=0 for
> small capacities; I don't recall if that was fixed.
>
> If you're using the pmem driver, it is incapable of queuing
> (submissions are immediately completed), so iodepth is
> irrelevant.
>
> There are other system and OS settings to tune, like:
> * use the performance governor. The userspace governor
> spends a lot of time making acpi_os_write calls
Had done, see not quoted part of my e-mail.
> * turn off auditing (audit=0 on the kernel command line)
> * turn off C states
Tried too.
Overall, I appreciate your help, but again, question is not how to improve my results.
The question is how to _decrease fio overhead_ with libaio, see subject of this e-mail.
It's very different question.
Thanks,
Vlad
next prev parent reply other threads:[~2016-03-03 3:03 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
2016-03-02 18:37 ` Elliott, Robert (Persistent Memory)
2016-03-03 3:03 ` Vladislav Bolkhovitin [this message]
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=56D7A964.3040809@vlnb.net \
--to=vst@vlnb.net \
--cc=elliott@hpe.com \
--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.