lkml.org 
[lkml]   [2019]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [xfs] 610125ab1e: fsmark.app_overhead -71.2% improvement
From
Date
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

\
 
 \ /
  Last update: 2019-09-09 08:08    [W:0.031 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site