Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jiri Horky <jiri.horky@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, fio@vger.kernel.org
Subject: Re: [PATCH] Allow to reset offset_increment counter
Date: Fri, 25 Jul 2014 09:47:16 +0200	[thread overview]
Message-ID: <53D20B84.4020403@gmail.com> (raw)
In-Reply-To: <538CC242.60109@gmail.com>

Hi Jens,

I wonder if you missed this email or you just didn't like the patch?

Regards
Jiri Horky

On 06/02/2014 08:28 PM, Jiri Horky wrote:
> Hi,
>
> so here is another try. I thought about it a little and I think that it
> only makes sense to define offset_increment together with numjobs=X
> setting, i.e. when using subjobs. The patch reflects this. Each subjob
> starts at next offset_increment for each file it operates on.
>
> Cheers
> Jirka H.
>
>
> On 05/23/2014 07:24 PM, Jiri Horky wrote:
>> Hi Jens,
>> On 05/23/2014 06:59 PM, Jens Axboe wrote:
>>> On 2014-05-23 06:48, Jiri Horky wrote:
>>>> Hi all,
>>>>
>>>> because I got bitten by this multiple times I decided to give this patch
>>>> a try :)
>>>>
>>>> Current implementation of offset calculation when offset_increment is in
>>>> effect uses global thread_number as follows:
>>>>      f->file_offset = td->o.start_offset + (td->thread_number - 1) *
>>>> td->o.offset_increment;
>>>>
>>>> The thread number gets incremented for every job (subjob) so even you
>>>> have multiple jobs with different filenames, the offset calculation is
>>>> shared. I find this very unintuitive, especially in cases the offsets
>>>> gets past the device/file. For example, if one wants to run sequential
>>>> read test in 16 threads of multiple devices (/dev/sd{b,c,d}) in one
>>>> group, which are of  1TB size, and to eliminate caching effect he wants
>>>> each read to start at different offset, the config could look like
>>>> following:
>>> Maybe it would be better to have this offset calculation be on a
>>> per-thread-per-file basis? You are right in that it only makes sense
>>> within the same file or device, so maybe it'd be better to make it
>>> work more like you expect.
>> I agree it should definitely be file-based, I just wasn't sure how you
>> would express that in the config file. Or you mean that that the offset
>> calculation would not be shared between different jobs (not subjobs)
>> even if they share the same file?
>> The fact is that one can always calculate the start offset in the new
>> job definition if he needs the offset calculation to be shared. And if
>> there are multiple files within a job, the offset_increment should be
>> independent.
>>
>> I will try to look at this.
>>
>> Jiri
>>



  reply	other threads:[~2014-07-25  7:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-23 12:48 [PATCH] Allow to reset offset_increment counter Jiri Horky
2014-05-23 16:59 ` Jens Axboe
2014-05-23 17:24   ` Jiri Horky
2014-06-02 18:28     ` Jiri Horky
2014-07-25  7:47       ` Jiri Horky [this message]
2014-07-25  7:51         ` Jens Axboe

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=53D20B84.4020403@gmail.com \
    --to=jiri.horky@gmail.com \
    --cc=axboe@kernel.dk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox