All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Suresh Dhanarajan <sureshdrajan@gmail.com>
Cc: fio@vger.kernel.org
Subject: Re: Running fio with offset Increment option
Date: Sat, 14 Apr 2012 17:29:45 +0200	[thread overview]
Message-ID: <4F8997E9.6090206@kernel.dk> (raw)
In-Reply-To: <4F899663.8050406@kernel.dk>

On 2012-04-14 17:23, Jens Axboe wrote:
> On 2012-04-14 01:48, Suresh Dhanarajan wrote:
>> Hi,
>>
>> I wanted to use the "offset increment option" and  "numjobs" so that i
>> can split the work load between ten jobs and reduce the run time.
>> But what i am seeing is that the offset counter is not getting reset
>> when the first job in the jobfile is completed.(is it that the offset
>> is global for the job file and not for the Jobs inside the jobfile?)
>> So  my read starts from the last offset set by the writes.
>>
>> here is my job file,
>>
>> [global]
>> bs=64k
>> direct=1
>> numjobs=10
>> size=1m
>> group_reporting
>>
>> [write-phase]
>> offset_increment=1m
>> filename=/dev/sdb
>> rw=write
>> write_iolog=verfywrite2
>>
>> [read-phase]
>> stonewall
>> offset_increment=1m
>> filename=/dev/sdb
>> rw=read
>> write_iolog=verfyread2
>>
>> I tried using the offset=0 option in the read phase job but now every
>> time the read happens from zeroth offsite.
>> Now the offset increment option is not getting honored.
>>
>> [write-phase]
>> offset_increment=1m
>> filename=/dev/sdb
>> rw=write
>> write_iolog=verfywrite2
>>
>> [read-phase]
>> stonewall
>> offset=0
>> offset_increment=1m
>> filename=/dev/sdb
>> rw=read
>> write_iolog=verfyread2
>>
>> I tried the same case with verify option.
>> the behavior is same.
>>
>> Is there any way that i can reset the offset counters once the job is completed?
> 
> Right now there isn't, but it does make sense to reset the counter
> across stonewalls. At the moment, it'll just increment for each job.
> Internally, fio sets up all the jobs, even across stonewalls, when it
> starts up. It just starts some of them later on, depending on those
> parameters. It does seem most useful to have it reset across a hard
> barrier though, I can definitely change it to do that.
> 
> Let me brew up a patch later today that you can test.

Had a few minutes now, didn't expect that. Can you try this? Do a make
clean first.

diff --git a/filesetup.c b/filesetup.c
index 166ace8..bad5bed 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -714,7 +714,7 @@ int setup_files(struct thread_data *td)
 	need_extend = 0;
 	for_each_file(td, f, i) {
 		f->file_offset = td->o.start_offset +
-			(td->thread_number - 1) * td->o.offset_increment;
+			(td->group_thread_number - 1) * td->o.offset_increment;
 
 		if (!td->o.file_size_low) {
 			/*
diff --git a/fio.h b/fio.h
index 95d9d77..05a5572 100644
--- a/fio.h
+++ b/fio.h
@@ -67,6 +67,7 @@ struct thread_data {
 	char verror[FIO_VERROR_SIZE];
 	pthread_t thread;
 	unsigned int thread_number;
+	unsigned int group_thread_number;
 	unsigned int groupid;
 	struct thread_stat ts;
 
diff --git a/init.c b/init.c
index 7422628..46571ee 100644
--- a/init.c
+++ b/init.c
@@ -35,6 +35,7 @@ static int dump_cmdline;
 static int def_timeout;
 
 static struct thread_data def_thread;
+static int group_thread_number;
 struct thread_data *threads = NULL;
 
 int exitall_on_terminate = 0;
@@ -829,8 +830,10 @@ static int add_job(struct thread_data *td, const char *jobname, int job_add_num,
 	if ((td->o.stonewall || td->o.new_group) && prev_group_jobs) {
 		prev_group_jobs = 0;
 		groupid++;
+		group_thread_number = 0;
 	}
 
+	td->group_thread_number = ++group_thread_number;
 	td->groupid = groupid;
 	prev_group_jobs++;
 

-- 
Jens Axboe


  reply	other threads:[~2012-04-14 15:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 23:48 Running fio with offset Increment option Suresh Dhanarajan
2012-04-14 15:23 ` Jens Axboe
2012-04-14 15:29   ` Jens Axboe [this message]
2012-04-16 23:15     ` Suresh Dhanarajan
2012-04-17  6:30       ` Jens Axboe
2012-04-18 21:37         ` Suresh Dhanarajan
2012-04-19  5:47           ` Jens Axboe
2012-04-19 19:32             ` Suresh Dhanarajan
2012-04-20  6:27               ` Jens Axboe
2012-04-28 19:09                 ` Suresh Dhanarajan
2012-05-02 12:12                   ` 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=4F8997E9.6090206@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    --cc=sureshdrajan@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.