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 -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
