From: Taisuke Yamada <tai@rakugaki.org>
To: fio@vger.kernel.org
Subject: [PATCH 1/2] Added replay_rebase option to run multi-threaded log replay on different disk sectors.
Date: Mon, 12 Sep 2011 14:30:03 +0900 [thread overview]
Message-ID: <4E6D98DB.7020106@rakugaki.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
> But since I also wanted to have each thread accessing different
> parts of the disk to increase a load, but still following the
> access pattern of the original, I added "replay_rebase" option to
> shift offset of IO request for each thread.
>
>> Thanks, I can see this being handy. I can apply this, but I would
>> much prefer if you resend it with the proper updates to HOWTO and
>> fio.1 adding the new option. Otherwise nobody is going to learn about it.
Yes, you're right.
Here's an updated patch with documentation.
Best Regards,
Signed-off-by: Taisuke Yamada <tai@rakugaki.org>
---
HOWTO | 9 +++++++++
fio.1 | 9 +++++++++
fio.h | 1 +
log.c | 2 +-
options.c | 8 ++++++++
5 files changed, 28 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-Added-replay_rebase-option-to-run-multi-threaded-log.patch --]
[-- Type: text/x-patch, Size: 3277 bytes --]
diff --git a/HOWTO b/HOWTO
index 724b604..132dc4a 100644
--- a/HOWTO
+++ b/HOWTO
@@ -1078,6 +1078,15 @@ replay_redirect=str While replaying I/O patterns using read_iolog the
independent fio invocations. Unfortuantely this also breaks
the strict time ordering between multiple device accesses.
+replay_rebase=int While replaying I/O patterns using read_iolog, the
+ default behavior is to replay the log as-is, even when
+ multiple threads are replaying the same log. This means
+ all threads are accessing the same sector on the device.
+ By specifying this option, each thread will be accessing
+ different sector by adding extra rebase offset. Offset is
+ simply given by "replay_rebase * internal thread number",
+ so IO access pattern itself is preserved.
+
write_bw_log=str If given, write a bandwidth log of the jobs in this job
file. Can be used to store data of the bandwidth of the
jobs in their lifetime. The included fio_generate_plots
diff --git a/fio.1 b/fio.1
index ffc97c9..702e4e3 100644
--- a/fio.1
+++ b/fio.1
@@ -823,6 +823,15 @@ is to replay the IOPS onto the major/minor device that each IOP was recorded
from. Setting \fBreplay_redirect\fR causes all IOPS to be replayed onto the
single specified device regardless of the device it was recorded from.
.TP
+.BI replay_rebase \fR=\fPint
+While replaying I/O patterns using read_iolog, the default behavior
+is to replay the log as-is, even when multiple threads are replaying
+the same log. This means all threads are accessing the same sector
+on the device. By specifying this option, each thread will be accessing
+different sector by adding extra rebase offset. Offset is simply given
+by "replay_rebase * internal thread number", so IO access pattern itself
+is preserved.
+.TP
.B write_bw_log \fR=\fPstr
If given, write a bandwidth log of the jobs in this job file. Can be used to
store data of the bandwidth of the jobs in their lifetime. The included
diff --git a/fio.h b/fio.h
index 6eb270d..b28e0ae 100644
--- a/fio.h
+++ b/fio.h
@@ -358,6 +358,7 @@ struct thread_options {
unsigned int gtod_offload;
enum fio_cs clocksource;
unsigned int no_stall;
+ unsigned int replay_rebase;
unsigned int trim_percentage;
unsigned int trim_batch;
unsigned int trim_zero;
diff --git a/log.c b/log.c
index f962864..57fc0f4 100644
--- a/log.c
+++ b/log.c
@@ -129,7 +129,7 @@ int read_iolog_get(struct thread_data *td, struct io_u *io_u)
io_u->ddir = ipo->ddir;
if (ipo->ddir != DDIR_WAIT) {
- io_u->offset = ipo->offset;
+ io_u->offset = ipo->offset + td->o.replay_rebase * td->thread_number;
io_u->buflen = ipo->len;
io_u->file = td->files[ipo->fileno];
get_file(io_u->file);
diff --git a/options.c b/options.c
index 74c24d0..aba14b1 100644
--- a/options.c
+++ b/options.c
@@ -1654,6 +1654,14 @@ static struct fio_option options[FIO_MAX_OPTS] = {
.help = "Replay all I/O onto this device, regardless of trace device",
},
{
+ .name = "replay_rebase",
+ .type = FIO_OPT_INT,
+ .off1 = td_var_offset(replay_rebase),
+ .def = "0",
+ .parent = "read_iolog",
+ .help = "Apply given offset for IO replay. Mainly for parallel replay.",
+ },
+ {
.name = "exec_prerun",
.type = FIO_OPT_STR_STORE,
.off1 = td_var_offset(exec_prerun),
next reply other threads:[~2011-09-12 5:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-12 5:30 Taisuke Yamada [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-09-09 5:12 [PATCH 1/2] Added replay_rebase option to run multi-threaded log replay on different disk sectors Taisuke Yamada
2011-09-09 8:37 ` Jens Axboe
2011-09-15 6:23 ` Taisuke Yamada
2011-09-15 11:10 ` Jens Axboe
2011-09-15 11:52 ` Taisuke Yamada
2011-09-15 11:14 ` Jens Axboe
2011-09-15 11:40 ` Taisuke Yamada
2011-09-15 11:42 ` 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=4E6D98DB.7020106@rakugaki.org \
--to=tai@rakugaki.org \
--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.