Re: [PATCH 5/5] Add option to specify ramp period by amount of IO

On Thu 18-12-25 10:19:12, Vincent Fu wrote:
> On Wed, Dec 17, 2025 at 11:17 AM Jan Kara <[email protected]> wrote:
> >
> > 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 <[email protected]>
> > ---
> >  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.
> > +
> 
> At the very least the documentation should explain how this options works with
> reporting groups.

Right, I'll improve that.

> Currently this patch compares the running total of the group's bytes to one
> job's value for ramp_size and then declares ramp time over for all jobs in
> the group if the threshold is exceeded. A little more thought should be put
> into potential use cases here. Should fio allow ramp_size to differ among jobs
> in a reporting group? Consider adding an option to enable/disable connections
> between jobs in the same reporting group.

My intention (somewhat inspired by the steadystate logic) was that IO of
all jobs in the group gets summed together and the specified limit is the
amount of IO for the whole group as well. This was motivated by the usecase
where you have multiple tasks doing buffered writes and you want ramp up to
terminate once they together write given amount of data. I didn't even think
of a case where ramp_size for different jobs in one group would be different.
Now that I'm checking steadystate logic, it rejects configs where different
jobs in a group have different configurations so if I add this consistency
check to ramp_size would you be fine with it?

I think connections between jobs are a bit of an overkill at this point - I
don't have a usecase for that...

								Honza

-- 
Jan Kara <[email protected]>
SUSE Labs, CR