* Re: [xfs] 610125ab1e: fsmark.app_overhead -71.2% improvement
[not found] <20190909015849.GN15734@shao2-debian>
@ 2019-09-09 5:32 ` Dave Chinner
2019-09-09 6:06 ` Rong Chen
0 siblings, 1 reply; 3+ messages in thread
From: Dave Chinner @ 2019-09-09 5:32 UTC (permalink / raw)
To: kernel test robot
Cc: Darrick J. Wong, Christoph Hellwig, LKML, linux-xfs, lkp
On Mon, Sep 09, 2019 at 09:58:49AM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -71.2% improvement of fsmark.app_overhead due to commit:
A negative improvement? That's somewhat ambiguous...
> 0e822255f95db400 610125ab1e4b1b48dcffe74d9d8
> ---------------- ---------------------------
> %stddev %change %stddev
> \ | \
> 1.095e+08 -71.2% 31557568 fsmark.app_overhead
> 6157 +95.5% 12034 fsmark.files_per_sec
So, the files/s rate doubled, and the amount of time spent in
userspace by the fsmark app dropped by 70%.
> 167.31 -47.3% 88.25 fsmark.time.elapsed_time
> 167.31 -47.3% 88.25 fsmark.time.elapsed_time.max
Wall time went down by 50%.
> 91.00 -8.8% 83.00 fsmark.time.percent_of_cpu_this_job_got
> 148.15 -53.2% 69.38 fsmark.time.system_time
As did system CPU.
IOWs, this change has changed create performance by a factor of 4 -
the file create is 2x faster for half the CPU spent.
I don't think this is a negative improvement - it's a large positive
improvement. I suspect that you need to change the metric
classifications for this workload...
Cheers,
Dave.
--
Dave Chinner
dchinner@redhat.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [xfs] 610125ab1e: fsmark.app_overhead -71.2% improvement
2019-09-09 5:32 ` [xfs] 610125ab1e: fsmark.app_overhead -71.2% improvement Dave Chinner
@ 2019-09-09 6:06 ` Rong Chen
2019-09-09 6:20 ` Dave Chinner
0 siblings, 1 reply; 3+ messages in thread
From: Rong Chen @ 2019-09-09 6:06 UTC (permalink / raw)
To: Dave Chinner; +Cc: Darrick J. Wong, Christoph Hellwig, LKML, linux-xfs, lkp
Hi Dave,
On 9/9/19 1:32 PM, Dave Chinner wrote:
> On Mon, Sep 09, 2019 at 09:58:49AM +0800, kernel test robot wrote:
>> Greeting,
>>
>> FYI, we noticed a -71.2% improvement of fsmark.app_overhead due to commit:
> A negative improvement? That's somewhat ambiguous...
Sorry for causing the misunderstanding, it's a improvement not a regression.
>
>> 0e822255f95db400 610125ab1e4b1b48dcffe74d9d8
>> ---------------- ---------------------------
>> %stddev %change %stddev
>> \ | \
>> 1.095e+08 -71.2% 31557568 fsmark.app_overhead
>> 6157 +95.5% 12034 fsmark.files_per_sec
> So, the files/s rate doubled, and the amount of time spent in
> userspace by the fsmark app dropped by 70%.
>
>> 167.31 -47.3% 88.25 fsmark.time.elapsed_time
>> 167.31 -47.3% 88.25 fsmark.time.elapsed_time.max
> Wall time went down by 50%.
>
>> 91.00 -8.8% 83.00 fsmark.time.percent_of_cpu_this_job_got
>> 148.15 -53.2% 69.38 fsmark.time.system_time
> As did system CPU.
>
> IOWs, this change has changed create performance by a factor of 4 -
> the file create is 2x faster for half the CPU spent.
>
> I don't think this is a negative improvement - it's a large positive
> improvement. I suspect that you need to change the metric
> classifications for this workload...
To avoid misunderstanding, we'll use fsmark.files_per_sec instead of
fsmark.app_overhead in the subject.
Best Regards,
Rong Chen
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [xfs] 610125ab1e: fsmark.app_overhead -71.2% improvement
2019-09-09 6:06 ` Rong Chen
@ 2019-09-09 6:20 ` Dave Chinner
0 siblings, 0 replies; 3+ messages in thread
From: Dave Chinner @ 2019-09-09 6:20 UTC (permalink / raw)
To: Rong Chen; +Cc: Darrick J. Wong, Christoph Hellwig, LKML, linux-xfs, lkp
On Mon, Sep 09, 2019 at 02:06:54PM +0800, Rong Chen wrote:
> Hi Dave,
>
> On 9/9/19 1:32 PM, Dave Chinner wrote:
> > On Mon, Sep 09, 2019 at 09:58:49AM +0800, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed a -71.2% improvement of fsmark.app_overhead due to commit:
> > A negative improvement? That's somewhat ambiguous...
>
> Sorry for causing the misunderstanding, it's a improvement not a regression.
>
>
> >
> > > 0e822255f95db400 610125ab1e4b1b48dcffe74d9d8
> > > ---------------- ---------------------------
> > > %stddev %change %stddev
> > > \ | \
> > > 1.095e+08 -71.2% 31557568 fsmark.app_overhead
> > > 6157 +95.5% 12034 fsmark.files_per_sec
> > So, the files/s rate doubled, and the amount of time spent in
> > userspace by the fsmark app dropped by 70%.
> >
> > > 167.31 -47.3% 88.25 fsmark.time.elapsed_time
> > > 167.31 -47.3% 88.25 fsmark.time.elapsed_time.max
> > Wall time went down by 50%.
> >
> > > 91.00 -8.8% 83.00 fsmark.time.percent_of_cpu_this_job_got
> > > 148.15 -53.2% 69.38 fsmark.time.system_time
> > As did system CPU.
> >
> > IOWs, this change has changed create performance by a factor of 4 -
> > the file create is 2x faster for half the CPU spent.
> >
> > I don't think this is a negative improvement - it's a large positive
> > improvement. I suspect that you need to change the metric
> > classifications for this workload...
> To avoid misunderstanding, we'll use fsmark.files_per_sec instead of
> fsmark.app_overhead in the subject.
Well, the two are separate ways of measuring improvement. A change
in one without a change in the other is just as significant as
a change in both...
Cheers,
Dave.
--
Dave Chinner
dchinner@redhat.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-09-09 6:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20190909015849.GN15734@shao2-debian>
2019-09-09 5:32 ` [xfs] 610125ab1e: fsmark.app_overhead -71.2% improvement Dave Chinner
2019-09-09 6:06 ` Rong Chen
2019-09-09 6:20 ` Dave Chinner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).