All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Fabrice Bacchella <fabrice.bacchella@orange.fr>, fio@vger.kernel.org
Subject: Re: IO merge in engine
Date: Fri, 2 Oct 2015 17:59:00 +0200	[thread overview]
Message-ID: <560EA9C4.6010402@kernel.dk> (raw)
In-Reply-To: <599D12BD-A1A9-42D7-ADE1-70ADACA9E177@orange.fr>

On 10/02/2015 04:04 PM, Fabrice Bacchella wrote:
> When writing my new hdfs engine, I met a problem with IO merge.
>
> If I submit IO that are bigger that what the hdfs can manage, I return them to fio as incomplete IO, the net engine works the same way :
> in engines/net.c, line 668+
> 			io_u->resid = io_u->xfer_buflen - ret;
> 			io_u->error = 0;
> 			return FIO_Q_COMPLETED;
>
> But the fio count them as two or more fast IO. I'm not sure it's a good measurement because if I'm simulating an application with fio, I expect to get the full IO latency and operations/s count. I don't mesure to mesure sub-io for that. For example, reducing the maximum transfer size will increase IO/s and reduce latency, even if the simulated application really sees reduced performance, because more of it's high level IO operation generated more real IO.
>
> Is there a way to prevent that in fio, or is that up to my engine to manage that and merge IO ?--

It sounds like a bug in the fio accounting, for the case of short 
reads/writes. That doesn't happen very often elsewhere, so not 
unreasonable to expect that is the case. Feel free to poke around and 
figure it out. Let me know if that doesn't work out, and I'll take a 
stab at fixing it up.

-- 
Jens Axboe



  reply	other threads:[~2015-10-02 15:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 14:04 IO merge in engine Fabrice Bacchella
2015-10-02 15:59 ` Jens Axboe [this message]
2015-10-06 15:36   ` Fabrice Bacchella

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=560EA9C4.6010402@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=fabrice.bacchella@orange.fr \
    --cc=fio@vger.kernel.org \
    /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.