Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Vladislav Bolkhovitin <vst@vlnb.net>
To: Jens Axboe <axboe@kernel.dk>, Sitsofe Wheeler <sitsofe@gmail.com>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: Fio high IOPS measurement mistake
Date: Fri, 04 Mar 2016 17:09:47 -0800	[thread overview]
Message-ID: <56DA31DB.5090507@vlnb.net> (raw)
In-Reply-To: <56DA2E49.2050207@kernel.dk>

Jens Axboe wrote on 03/04/2016 04:54 PM:
>>> I've seen you bring up this contention idea before.
>>
>> Yes, it was when I forgot to short circuit lseek calls in the sync engine. Usually, if
>> you see performance dropping from certain number of threads, it is safe to guess there
>> is a lock contention somewhere.
> 
> That is true, the lseek() part is not in fio though, that's a kernel issue. But for
> this case, avoiding lseek through one of the sync variants with offset is the best
> solution. Might actually makes sense to make that the default.

BTW, as far as I can see, fio is using independent, fully dedicated file handles for
each job. Shouldn't independent file handles, ever for the same block device, behave
fully independently with nothing shared, hence protected by locks?

In my naive understanding, lseek should be just changing internal offset, a single
variable. Perhaps, translation fd (integer) -> corresponding internal structure is what
to blame here (also pure guess).

>>> Is that pure guesswork on your end, or have you profiled any contention?
>>
>> Pure guesswork. I'm looking at fio in details only few days, so it is still pretty much
>> a black box for me. Generally, if you see performance drop with another thread, it must
>> be either locks contention, or communication overhead. Nowadays the former is more
>> common, hence the guess.
> 
> Right, but that contention can be anywhere from the application to the driver. So some
> more details would be great, when you have them.
> 
> One thing I've seen for higher IOPS cases is that the bdev inode inc/dec for every IO,
> that hurts scalability. That was fixed here:
> 
> http://git.kernel.dk/cgit/linux-block/commit/?id=fe0f07d08ee35
> 
> but you might already be running a kernel with that included (what are you running?).
> Another one is the io stats collected, that tends to cause poorer scaling than you
> would expect, you can turn that off through sysfs (/sys/block/<dev>/queue/iostats).

Thanks, I'm planning to update to the latest kernel and try with it.

Vlad



  reply	other threads:[~2016-03-05  1:09 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
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 [this message]
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=56DA31DB.5090507@vlnb.net \
    --to=vst@vlnb.net \
    --cc=axboe@kernel.dk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox