Should group_reporting be clumping together different groups?

Should group_reporting be clumping together different groups?

[Akash Verma]

Let's say I use FIO with the following job file:


[group_1]
rw=randwrite
size=1024k
ioengine=libaio
time_based=1
runtime=10
direct=1
do_verify=0
numjobs=2
group_reporting=1

[group_2]
rw=randread
size=1024k
ioengine=libaio
time_based=1
runtime=10
direct=1
numjobs=2
group_reporting=1


I get a single report, named after group_1 but actually including
results for group_2 as well. Since I'm using group_reporting with
numjobs, shouldn't I be getting two reports, one for group_1 and one
for group_2?

I am able to get the desired functionality using:
new_group=1
under group_2, causing FIO to specifically treat that group as
separate for reporting purposes. However the current behavior still
doesn't conform with the description given for both group_reporting
and new_group.

Thanks,
Akash

Re: Should group_reporting be clumping together different groups?

[Jens Axboe]

On 2012-09-29 04:11, Akash Verma wrote:
> Let's say I use FIO with the following job file:
> 
> 
> [group_1]
> rw=randwrite
> size=1024k
> ioengine=libaio
> time_based=1
> runtime=10
> direct=1
> do_verify=0
> numjobs=2
> group_reporting=1
> 
> [group_2]
> rw=randread
> size=1024k
> ioengine=libaio
> time_based=1
> runtime=10
> direct=1
> numjobs=2
> group_reporting=1
> 
> 
> I get a single report, named after group_1 but actually including
> results for group_2 as well. Since I'm using group_reporting with
> numjobs, shouldn't I be getting two reports, one for group_1 and one
> for group_2?
> 
> I am able to get the desired functionality using:
> new_group=1
> under group_2, causing FIO to specifically treat that group as
> separate for reporting purposes. However the current behavior still
> doesn't conform with the description given for both group_reporting
> and new_group.

Hmm, I think it's perfectly aligned with what is described. The
documentation states that jobs are part of the same group, except if:

- They are separated by a stone wall, which implies starting a new
  group.

- or the new_group primitive is used explicitly.

-- 
Jens Axboe

Re: Should group_reporting be clumping together different groups?

[Akash Verma]

[-- Attachment #1: Type: text/plain, Size: 2967 bytes --]

That's odd, because I understood it differently. I have gone through the
HOWTO again to be sure. Please bear with me; I'm copying succeeding lines
from the HOWTO from version 2.0.9:

new_group Start a new reporting group. If this option isn't given,
jobs in a file will be part of the same reporting group
 unless separated by a stone wall (or if it's a group
by itself, with the numjobs option).

numjobs=int Create the specified number of clones of this job. May be
used to setup a larger number of threads/processes doing
 the same thing. We regard that grouping of jobs as a
specific group.

group_reporting If 'numjobs' is set, it may be interesting to display
 statistics for the group as a whole instead of for each
individual job. This is especially true of 'numjobs' is
 large, looking at individual thread/process output quickly
becomes unwieldy. If 'group_reporting' is specified, fio
 will show the final report per-group instead of per-job.

Is it just me? Reading that, I don't see any confusion about the
group_reporting flag being specifically for clumping together results that
would otherwise be discrete for each job clone because of numjobs.

Even here, the description for new_group implies that jobs in a job file
are in the same reporting group, unless <condition 1> and <condition 2>.
But it seems to be the default behavior to not have them in the same
reporting group. For example, I used the file included in the first email,
but without numjobs and group_reporting. Then I get one report for each job.

In my opinion, the current functionality is fine, but the documentation
isn't clear on it.

Thanks,
Akash


On Fri, Sep 28, 2012 at 11:26 PM, Jens Axboe <axboe@kernel.dk> wrote:

> On 2012-09-29 04:11, Akash Verma wrote:
> > Let's say I use FIO with the following job file:
> >
> >
> > [group_1]
> > rw=randwrite
> > size=1024k
> > ioengine=libaio
> > time_based=1
> > runtime=10
> > direct=1
> > do_verify=0
> > numjobs=2
> > group_reporting=1
> >
> > [group_2]
> > rw=randread
> > size=1024k
> > ioengine=libaio
> > time_based=1
> > runtime=10
> > direct=1
> > numjobs=2
> > group_reporting=1
> >
> >
> > I get a single report, named after group_1 but actually including
> > results for group_2 as well. Since I'm using group_reporting with
> > numjobs, shouldn't I be getting two reports, one for group_1 and one
> > for group_2?
> >
> > I am able to get the desired functionality using:
> > new_group=1
> > under group_2, causing FIO to specifically treat that group as
> > separate for reporting purposes. However the current behavior still
> > doesn't conform with the description given for both group_reporting
> > and new_group.
>
> Hmm, I think it's perfectly aligned with what is described. The
> documentation states that jobs are part of the same group, except if:
>
> - They are separated by a stone wall, which implies starting a new
>   group.
>
> - or the new_group primitive is used explicitly.
>
> --
> Jens Axboe
>
>

[-- Attachment #2: Type: text/html, Size: 4697 bytes --]

Re: Should group_reporting be clumping together different groups?

[Akash Verma]

That's odd, because I understood it differently. I have gone through
the HOWTO again to be sure. Please bear with me; I'm copying
succeeding lines from the HOWTO from version 2.0.9:

new_group Start a new reporting group. If this option isn't given,
jobs in a file will be part of the same reporting group
unless separated by a stone wall (or if it's a group
by itself, with the numjobs option).

numjobs=int Create the specified number of clones of this job. May be
used to setup a larger number of threads/processes doing
the same thing. We regard that grouping of jobs as a
specific group.

group_reporting If 'numjobs' is set, it may be interesting to display
statistics for the group as a whole instead of for each
individual job. This is especially true of 'numjobs' is
large, looking at individual thread/process output quickly
becomes unwieldy. If 'group_reporting' is specified, fio
will show the final report per-group instead of per-job.

Is it just me? Reading that, I don't see any confusion about the
group_reporting flag being specifically for clumping together results
that would otherwise be discrete for each job clone because of
numjobs.

Even here, the description for new_group implies that jobs in a job
file are in the same reporting group, unless <condition 1> and
<condition 2>. But it seems to be the default behavior to not have
them in the same reporting group. For example, I used the file
included in the first email, but without numjobs and group_reporting.
Then I get one report for each job.

In my opinion, the current functionality is fine, but the
documentation isn't clear on it.

Thanks,
Akash

On Fri, Sep 28, 2012 at 11:26 PM, Jens Axboe <axboe@kernel.dk> wrote:
> On 2012-09-29 04:11, Akash Verma wrote:
>> Let's say I use FIO with the following job file:
>>
>>
>> [group_1]
>> rw=randwrite
>> size=1024k
>> ioengine=libaio
>> time_based=1
>> runtime=10
>> direct=1
>> do_verify=0
>> numjobs=2
>> group_reporting=1
>>
>> [group_2]
>> rw=randread
>> size=1024k
>> ioengine=libaio
>> time_based=1
>> runtime=10
>> direct=1
>> numjobs=2
>> group_reporting=1
>>
>>
>> I get a single report, named after group_1 but actually including
>> results for group_2 as well. Since I'm using group_reporting with
>> numjobs, shouldn't I be getting two reports, one for group_1 and one
>> for group_2?
>>
>> I am able to get the desired functionality using:
>> new_group=1
>> under group_2, causing FIO to specifically treat that group as
>> separate for reporting purposes. However the current behavior still
>> doesn't conform with the description given for both group_reporting
>> and new_group.
>
> Hmm, I think it's perfectly aligned with what is described. The
> documentation states that jobs are part of the same group, except if:
>
> - They are separated by a stone wall, which implies starting a new
>   group.
>
> - or the new_group primitive is used explicitly.
>
> --
> Jens Axboe
>

Re: Should group_reporting be clumping together different groups?

[Jens Axboe]

On 2012-09-29 09:32, Akash Verma wrote:
> That's odd, because I understood it differently. I have gone through
> the HOWTO again to be sure. Please bear with me; I'm copying
> succeeding lines from the HOWTO from version 2.0.9:
> 
> new_groupStart a new reporting group. If this option isn't given,
> jobs in a file will be part of the same reporting group
> unless separated by a stone wall (or if it's a group
> by itself, with the numjobs option).
> 
> numjobs=intCreate the specified number of clones of this job. May be
> used to setup a larger number of threads/processes doing
> the same thing. We regard that grouping of jobs as a
> specific group.
> 
> group_reportingIf 'numjobs' is set, it may be interesting to display
> statistics for the group as a whole instead of for each
> individual job. This is especially true of 'numjobs' is
> large, looking at individual thread/process output quickly
> becomes unwieldy. If 'group_reporting' is specified, fio
> will show the final report per-group instead of per-job.
> 
> Is it just me? Reading that, I don't see any confusion about the
> group_reporting flag being specifically for clumping together results
> that would otherwise be discrete for each job clone because of
> numjobs.
> 
> Even here, the description for new_group implies that jobs in a job
> file are in the same reporting group, unless <condition 1> and
> <condition 2>. But it seems to be the default behavior to not have
> them in the same reporting group. For example, I used the file
> included in the first email, but without numjobs and group_reporting.
> Then I get one report for each job.
> 
> In my opinion, the current functionality is fine, but the
> documentation isn't clear on it.

OK, I see what you mean wrt numjobs=. It is implied that this
constitutes a group of its own, which it doesn't. I agree that the
current behavior is fine, in fact it'd be a bother if numjobs= did imply
a new group. I'll get the documentation updated for that specific case
soon - or I'll take a patch as well, of course :-)

-- 
Jens Axboe

Re: Should group_reporting be clumping together different groups?

[Akash Verma]

Thanks Jens. So now with my new understanding of things, my
expectation is that running FIO with a job file like this:

[job_1]
rw=randwrite
size=1024k
ioengine=libaio
time_based=1
runtime=10
direct=1
do_verify=0

[job_2]
rw=randread
size=1024k
ioengine=libaio
time_based=1
runtime=10
direct=1

It's the same reporting group, so I expect a single output. However I
actually get one output each. Is this a bug? - or do I need to go get
some sleep and look at the whole thing again tomorrow :-|

Thanks,
Akash

On Sat, Sep 29, 2012 at 12:59 AM, Jens Axboe <axboe@kernel.dk> wrote:
> On 2012-09-29 09:32, Akash Verma wrote:
>> That's odd, because I understood it differently. I have gone through
>> the HOWTO again to be sure. Please bear with me; I'm copying
>> succeeding lines from the HOWTO from version 2.0.9:
>>
>> new_groupStart a new reporting group. If this option isn't given,
>> jobs in a file will be part of the same reporting group
>> unless separated by a stone wall (or if it's a group
>> by itself, with the numjobs option).
>>
>> numjobs=intCreate the specified number of clones of this job. May be
>> used to setup a larger number of threads/processes doing
>> the same thing. We regard that grouping of jobs as a
>> specific group.
>>
>> group_reportingIf 'numjobs' is set, it may be interesting to display
>> statistics for the group as a whole instead of for each
>> individual job. This is especially true of 'numjobs' is
>> large, looking at individual thread/process output quickly
>> becomes unwieldy. If 'group_reporting' is specified, fio
>> will show the final report per-group instead of per-job.
>>
>> Is it just me? Reading that, I don't see any confusion about the
>> group_reporting flag being specifically for clumping together results
>> that would otherwise be discrete for each job clone because of
>> numjobs.
>>
>> Even here, the description for new_group implies that jobs in a job
>> file are in the same reporting group, unless <condition 1> and
>> <condition 2>. But it seems to be the default behavior to not have
>> them in the same reporting group. For example, I used the file
>> included in the first email, but without numjobs and group_reporting.
>> Then I get one report for each job.
>>
>> In my opinion, the current functionality is fine, but the
>> documentation isn't clear on it.
>
> OK, I see what you mean wrt numjobs=. It is implied that this
> constitutes a group of its own, which it doesn't. I agree that the
> current behavior is fine, in fact it'd be a bother if numjobs= did imply
> a new group. I'll get the documentation updated for that specific case
> soon - or I'll take a patch as well, of course :-)
>
> --
> Jens Axboe
>

Re: Should group_reporting be clumping together different groups?

[Akash Verma]

Ah, I finally got what "group" means here. Ignore last mail.

On Sat, Sep 29, 2012 at 1:08 AM, Akash Verma <akashv@google.com> wrote:
> Thanks Jens. So now with my new understanding of things, my
> expectation is that running FIO with a job file like this:
>
> [job_1]
> rw=randwrite
> size=1024k
> ioengine=libaio
> time_based=1
> runtime=10
> direct=1
> do_verify=0
>
> [job_2]
> rw=randread
> size=1024k
> ioengine=libaio
> time_based=1
> runtime=10
> direct=1
>
> It's the same reporting group, so I expect a single output. However I
> actually get one output each. Is this a bug? - or do I need to go get
> some sleep and look at the whole thing again tomorrow :-|
>
> Thanks,
> Akash
>
> On Sat, Sep 29, 2012 at 12:59 AM, Jens Axboe <axboe@kernel.dk> wrote:
>> On 2012-09-29 09:32, Akash Verma wrote:
>>> That's odd, because I understood it differently. I have gone through
>>> the HOWTO again to be sure. Please bear with me; I'm copying
>>> succeeding lines from the HOWTO from version 2.0.9:
>>>
>>> new_groupStart a new reporting group. If this option isn't given,
>>> jobs in a file will be part of the same reporting group
>>> unless separated by a stone wall (or if it's a group
>>> by itself, with the numjobs option).
>>>
>>> numjobs=intCreate the specified number of clones of this job. May be
>>> used to setup a larger number of threads/processes doing
>>> the same thing. We regard that grouping of jobs as a
>>> specific group.
>>>
>>> group_reportingIf 'numjobs' is set, it may be interesting to display
>>> statistics for the group as a whole instead of for each
>>> individual job. This is especially true of 'numjobs' is
>>> large, looking at individual thread/process output quickly
>>> becomes unwieldy. If 'group_reporting' is specified, fio
>>> will show the final report per-group instead of per-job.
>>>
>>> Is it just me? Reading that, I don't see any confusion about the
>>> group_reporting flag being specifically for clumping together results
>>> that would otherwise be discrete for each job clone because of
>>> numjobs.
>>>
>>> Even here, the description for new_group implies that jobs in a job
>>> file are in the same reporting group, unless <condition 1> and
>>> <condition 2>. But it seems to be the default behavior to not have
>>> them in the same reporting group. For example, I used the file
>>> included in the first email, but without numjobs and group_reporting.
>>> Then I get one report for each job.
>>>
>>> In my opinion, the current functionality is fine, but the
>>> documentation isn't clear on it.
>>
>> OK, I see what you mean wrt numjobs=. It is implied that this
>> constitutes a group of its own, which it doesn't. I agree that the
>> current behavior is fine, in fact it'd be a bother if numjobs= did imply
>> a new group. I'll get the documentation updated for that specific case
>> soon - or I'll take a patch as well, of course :-)
>>
>> --
>> Jens Axboe
>>