Linux-XFS Archive on lore.kernel.org
 help / color / Atom feed
* 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, back to index

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

Linux-XFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-xfs/0 linux-xfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-xfs linux-xfs/ https://lore.kernel.org/linux-xfs \
		linux-xfs@vger.kernel.org linux-xfs@archiver.kernel.org
	public-inbox-index linux-xfs


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-xfs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox