Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression

[Jaegeuk Kim]

Hi Huang,

On Thu, Aug 04, 2016 at 10:00:41AM -0700, Huang, Ying wrote:
> Hi, Jaegeuk,
> 
> "Huang, Ying" <ying.huang@xxxxxxxxx> writes:
> > Hi,
> >
> > I checked the comparison result below and found this is a regression for
> > fsmark.files_per_sec, not fsmark.app_overhead.
> >
> > Best Regards,
> > Huang, Ying
> >
> > kernel test robot <xiaolong.ye@xxxxxxxxx> writes:
> >
> >> FYI, we noticed a -36.3% regression of fsmark.files_per_sec due to commit:
> >>
> >> commit ec795418c41850056feb956534edf059dc1155d4 ("f2fs: use percpu_rw_semaphore")
> >> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev-test
> 
> I found this has been merged by upstream.  Do you have some plan to fix
> it?  Or you think the test itself has some problem?

Sorry, too busy to take a look at this.
The patch implements percpu_rw_semaphore which is intended to enhance FS
scalability. Since I couldn't see any big regression in my test cases, could you
check any debugging options which may give some overheads?

Let me recheck this with whole my tests.

Thanks,

> 
> We have another 2 regressions
> 
> - [lkp] [f2fs] 3bdad3c7ee: aim7.jobs-per-min -25.3% regression
> - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% regression
> 
> they are merged by upstream now too.  So same questions for them too.
> 
> Best Regards,
> Huang, Ying
> 
> >> in testcase: fsmark
> >> on test machine: 72 threads Haswell-EP with 128G memory
> >> with following parameters:
> > cpufreq_governor=performance/disk=1SSD/filesize=8K/fs=f2fs/iterations=8/nr_directories=16d/nr_files_per_directory=256fpd/nr_threads=4/sync_method=fsyncBeforeClose/test_size=72G
> >>
> >>
> >>
> >> Disclaimer:
> >> Results have been estimated based on internal Intel analysis and are provided
> >> for informational purposes only. Any difference in system hardware or software
> >> design or configuration may affect actual performance.
> >>