* 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).