From: Jan Kara <jack@suse.cz>
To: fio@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>, Vincent Fu <vincentfu@gmail.com>,
Jan Kara <jack@suse.cz>
Subject: [PATCH 5/5] Add option to specify ramp period by amount of IO
Date: Wed, 17 Dec 2025 17:17:15 +0100 [thread overview]
Message-ID: <20251217161722.6357-5-jack@suse.cz> (raw)
In-Reply-To: <20251217160217.15533-1-jack@suse.cz>
In some cases the ramp up period is not easy to define by amount of
time. This is for example a case of buffered writes measurement where we
want to start measuring only once dirty throttling kicks in. The time
until dirty throttling kicks in depends on dirty limit (easy to figure
out) and speed of writes to the page cache (difficult to know in
advance). Add option ramp_size which determines the ramp up period by
the amount of IO written (either by each job or by each group when group
reporting is enabled).
Signed-off-by: Jan Kara <jack@suse.cz>
---
HOWTO.rst | 7 +++++++
fio.1 | 6 ++++++
options.c | 11 +++++++++++
thread_options.h | 2 ++
time.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++--
5 files changed, 74 insertions(+), 2 deletions(-)
diff --git a/HOWTO.rst b/HOWTO.rst
index 9f55a73bde05..49ebae6275a6 100644
--- a/HOWTO.rst
+++ b/HOWTO.rst
@@ -715,6 +715,13 @@ Time related parameters
:option:`runtime` is specified. When the unit is omitted, the value is
given in seconds.
+.. option:: ramp_size=size
+
+ If set, fio will wait until the workload does given amount of IO before
+ logging any performance numbers. Similar considerations apply as for
+ ``ramp_time`` option. When the unit is omitted, the value is given in
+ megabytes.
+
.. option:: clocksource=str
Use the given clocksource as the base of timing. The supported options are:
diff --git a/fio.1 b/fio.1
index 9c4ff08c86ad..88e97518f853 100644
--- a/fio.1
+++ b/fio.1
@@ -497,6 +497,12 @@ thus it will increase the total runtime if a special timeout or
\fBruntime\fR is specified. When the unit is omitted, the value is
given in seconds.
.TP
+.BI ramp_size \fR=\fPsize
+If set, fio will wait until the workload does given amount of IO before
+logging any performance numbers. Similar considerations apply as for
+\fBramp_time\fR option. When the unit is omitted, the value is given in
+megabytes.
+.TP
.BI clocksource \fR=\fPstr
Use the given clocksource as the base of timing. The supported options are:
.RS
diff --git a/options.c b/options.c
index 8e3de528bbbb..d050a1f6a417 100644
--- a/options.c
+++ b/options.c
@@ -3093,6 +3093,17 @@ struct fio_option fio_options[FIO_MAX_OPTS] = {
.category = FIO_OPT_C_GENERAL,
.group = FIO_OPT_G_RUNTIME,
},
+ {
+ .name = "ramp_size",
+ .lname = "Ramp size",
+ .type = FIO_OPT_STR_VAL,
+ .off1 = offsetof(struct thread_options, ramp_size),
+ .minval = 1,
+ .help = "Amount of data transferred before measuring performance",
+ .interval = 1024 * 1024,
+ .category = FIO_OPT_C_GENERAL,
+ .group = FIO_OPT_G_RUNTIME,
+ },
{
.name = "clocksource",
.lname = "Clock source",
diff --git a/thread_options.h b/thread_options.h
index 3abce7318ce2..b4dd8d7acd49 100644
--- a/thread_options.h
+++ b/thread_options.h
@@ -212,6 +212,7 @@ struct thread_options {
unsigned long long start_delay_high;
unsigned long long timeout;
unsigned long long ramp_time;
+ unsigned long long ramp_size;
unsigned int ss_state;
fio_fp64_t ss_limit;
unsigned long long ss_dur;
@@ -546,6 +547,7 @@ struct thread_options_pack {
uint64_t start_delay_high;
uint64_t timeout;
uint64_t ramp_time;
+ uint64_t ramp_size;
uint64_t ss_dur;
uint64_t ss_ramp_time;
uint32_t ss_state;
diff --git a/time.c b/time.c
index 2709d5b9784a..d2a201bb262c 100644
--- a/time.c
+++ b/time.c
@@ -125,11 +125,57 @@ bool ramp_period_enabled = false;
int ramp_period_check(void)
{
+ uint64_t group_bytes = 0;
+ int prev_groupid = -1;
+ bool group_ramp_period_over = false;
+
for_each_td(td) {
if (td->ramp_period_state != RAMP_RUNNING)
continue;
- if (utime_since_now(&td->epoch) >= td->o.ramp_time)
+
+ if (td->o.ramp_time &&
+ utime_since_now(&td->epoch) >= td->o.ramp_time) {
td->ramp_period_state = RAMP_FINISHING;
+ continue;
+ }
+
+ if (td->o.ramp_size) {
+ int ddir;
+ const bool needs_lock = td_async_processing(td);
+
+ if (!td->o.group_reporting ||
+ (td->o.group_reporting &&
+ td->groupid != prev_groupid)) {
+ group_bytes = 0;
+ prev_groupid = td->groupid;
+ group_ramp_period_over = false;
+ }
+
+ if (needs_lock)
+ __td_io_u_lock(td);
+
+ for (ddir = 0; ddir < DDIR_RWDIR_CNT; ddir++)
+ group_bytes += td->io_bytes[ddir];
+
+ if (needs_lock)
+ __td_io_u_unlock(td);
+
+ if (group_bytes >= td->o.ramp_size) {
+ td->ramp_period_state = RAMP_FINISHING;
+ /*
+ * Mark ramp up for all threads in the group as
+ * done.
+ */
+ if (td->o.group_reporting &&
+ !group_ramp_period_over) {
+ group_ramp_period_over = true;
+ for_each_td(td2) {
+ if (td2->groupid == td->groupid)
+ td2->ramp_period_state = RAMP_FINISHING;
+ } end_for_each();
+ }
+ }
+ }
} end_for_each();
return 0;
@@ -175,7 +221,7 @@ bool ramp_period_over(struct thread_data *td)
void td_ramp_period_init(struct thread_data *td)
{
- if (td->o.ramp_time) {
+ if (td->o.ramp_time || td->o.ramp_size) {
td->ramp_period_state = RAMP_RUNNING;
ramp_period_enabled = true;
} else {
--
2.51.0
next prev parent reply other threads:[~2025-12-17 16:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 16:17 [PATCH 0/5] Add support for specifying ramp up period by amount of IO Jan Kara
2025-12-17 16:17 ` [PATCH 1/5] time: rename in_ramp_time() and ramp_time_over() Jan Kara
2025-12-17 22:52 ` Damien Le Moal
2025-12-19 3:53 ` fiotestbot
2025-12-17 16:17 ` [PATCH 2/5] td: Initialize ramp_period_over based on options Jan Kara
2025-12-17 22:53 ` Damien Le Moal
2025-12-17 16:17 ` [PATCH 3/5] eta: Use in_ramp_period() instead of opencoding it Jan Kara
2025-12-17 22:55 ` Damien Le Moal
2025-12-17 16:17 ` [PATCH 4/5] time: Evaluate ramp up condition once per second Jan Kara
2025-12-17 22:58 ` Damien Le Moal
2025-12-17 16:17 ` Jan Kara [this message]
2025-12-17 22:56 ` [PATCH 5/5] Add option to specify ramp period by amount of IO Jens Axboe
2025-12-18 17:18 ` Jan Kara
2025-12-17 23:03 ` Damien Le Moal
2025-12-18 16:31 ` Jan Kara
2025-12-19 8:12 ` Damien Le Moal
2025-12-19 13:10 ` Jan Kara
2025-12-18 15:19 ` Vincent Fu
2025-12-18 17:18 ` Jan Kara
2025-12-18 21:42 ` Vincent Fu
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=20251217161722.6357-5-jack@suse.cz \
--to=jack@suse.cz \
--cc=axboe@kernel.dk \
--cc=fio@vger.kernel.org \
--cc=vincentfu@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