* Re: [LKP] [lkp-robot] [nfsd4] 517dc52baa: fsmark.files_per_sec 32.4% improvement [not found] ` <20180727002225.GF17169@yexl-desktop> @ 2018-08-01 11:46 ` J. Bruce Fields 2018-08-07 5:02 ` Rong Chen 0 siblings, 1 reply; 3+ messages in thread From: J. Bruce Fields @ 2018-08-01 11:46 UTC (permalink / raw) To: Ye Xiaolong; +Cc: Stephen Rothwell, linux-nfs, lkp, LKML, Chen, Rong A On Fri, Jul 27, 2018 at 08:22:25AM +0800, Ye Xiaolong wrote: > On 07/16, Ye Xiaolong wrote: > >On 07/04, Huang, Ying wrote: > >>"J. Bruce Fields" <bfields@redhat.com> writes: > >> > >>> Thanks! > >>> > >>> On Wed, Jun 20, 2018 at 02:52:43PM +0800, kernel test robot wrote: > >>>> FYI, we noticed a 32.4% improvement of fsmark.files_per_sec due to commit: > >>>> > >>>> > >>>> commit: 517dc52baa2a508c82f68bbc7219b48169e6b29f ("nfsd4: shortern default lease period") > >>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master > >>> > >>> That doesn't make any sense.... > >>> > >>> OK, I think I see the problem: > >>> > >>>> in testcase: fsmark > >>>> on test machine: 48 threads Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz with 64G memory > >>>> with following parameters: > >>>> > >>>> iterations: 1x > >>>> nr_threads: 1t > >>>> disk: 1BRD_48G > >>>> fs: f2fs > >>>> fs2: nfsv4 > >>>> filesize: 4M > >>>> test_size: 40G > >>>> sync_method: fsyncBeforeClose > >>>> cpufreq_governor: performance > >>>> > >>>> test-description: The fsmark is a file system benchmark to test synchronous write workloads, for example, mail servers workload. > >>>> test-url: https://sourceforge.net/projects/fsmark/ > >>>> > >>>> > >>>> > >>>> Details are as below: > >>>> --------------------------------------------------------------------------------------------------> > >>>> > >>>> > >>>> To reproduce: > >>>> > >>>> git clone https://github.com/intel/lkp-tests.git > >>>> cd lkp-tests > >>>> bin/lkp install job.yaml # job file is attached in this email > >>>> bin/lkp run job.yaml > >>>> > >>>> ========================================================================================= > >>>> compiler/cpufreq_governor/disk/filesize/fs2/fs/iterations/kconfig/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase: > >>>> gcc-7/performance/1BRD_48G/4M/nfsv4/f2fs/1x/x86_64-rhel-7.2/1t/debian-x86_64-2016-08-31.cgz/fsyncBeforeClose/ivb44/40G/fsmark > >>>> > >>>> commit: > >>>> c2993a1d7d ("nfsd4: extend reclaim period for reclaiming clients") > >>>> 517dc52baa ("nfsd4: shortern default lease period") > >>>> > >>>> c2993a1d7d6687fd 517dc52baa2a508c82f68bbc72 > >>>> ---------------- -------------------------- > >>>> %stddev %change %stddev > >>>> \ | \ > >>>> 53.60 +32.4% 70.95 fsmark.files_per_sec > >>>> 191.89 -24.4% 145.16 fsmark.time.elapsed_time > >>>> 191.89 -24.4% 145.16 fsmark.time.elapsed_time.max > >>> > >>> So what happened is the test took about 45 seconds less. > >>> > >>> I suspect you're starting the nfs server and then immediately running > >>> this test. > >> > >>Yes. > >> > >>> The problem is that if there's a grace period on startup, any open will > >>> just hang until the grace period ends. > >>> > >>> This patch changed the default grace period from 90 seconds to 45, so > >>> that would explain the change. > >>> > >>> In my testing I usually > >>> > >>> start the nfs server > >>> on the client: > >>> mount the server > >>> touch a file > >>> > >>> When the touch returns, I know any grace period has completed, and then > >>> I can run any tests normally. > >> > > > >I've modified our test to touch a file before running the actual workload, then > >requeue tests for both commit 517dc52baa and its parent c2993a1d7d, but the > >result seems persistent which shows a ~30% improvement of fsmark.files_per_sec. > > > > Any suggestions? You're sure you only start timing after the "touch" returns? --b. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LKP] [lkp-robot] [nfsd4] 517dc52baa: fsmark.files_per_sec 32.4% improvement 2018-08-01 11:46 ` [LKP] [lkp-robot] [nfsd4] 517dc52baa: fsmark.files_per_sec 32.4% improvement J. Bruce Fields @ 2018-08-07 5:02 ` Rong Chen 2018-08-07 14:16 ` J. Bruce Fields 0 siblings, 1 reply; 3+ messages in thread From: Rong Chen @ 2018-08-07 5:02 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Ye Xiaolong, Stephen Rothwell, linux-nfs, lkp, LKML On 08/01/2018 07:46 PM, J. Bruce Fields wrote: > On Fri, Jul 27, 2018 at 08:22:25AM +0800, Ye Xiaolong wrote: >> On 07/16, Ye Xiaolong wrote: >>> On 07/04, Huang, Ying wrote: >>>> "J. Bruce Fields" <bfields@redhat.com> writes: >>>> >>>>> Thanks! >>>>> >>>>> On Wed, Jun 20, 2018 at 02:52:43PM +0800, kernel test robot wrote: >>>>>> FYI, we noticed a 32.4% improvement of fsmark.files_per_sec due to commit: >>>>>> >>>>>> >>>>>> commit: 517dc52baa2a508c82f68bbc7219b48169e6b29f ("nfsd4: shortern default lease period") >>>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master >>>>> That doesn't make any sense.... >>>>> >>>>> OK, I think I see the problem: >>>>> >>>>>> in testcase: fsmark >>>>>> on test machine: 48 threads Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz with 64G memory >>>>>> with following parameters: >>>>>> >>>>>> iterations: 1x >>>>>> nr_threads: 1t >>>>>> disk: 1BRD_48G >>>>>> fs: f2fs >>>>>> fs2: nfsv4 >>>>>> filesize: 4M >>>>>> test_size: 40G >>>>>> sync_method: fsyncBeforeClose >>>>>> cpufreq_governor: performance >>>>>> >>>>>> test-description: The fsmark is a file system benchmark to test synchronous write workloads, for example, mail servers workload. >>>>>> test-url: https://sourceforge.net/projects/fsmark/ >>>>>> >>>>>> >>>>>> >>>>>> Details are as below: >>>>>> --------------------------------------------------------------------------------------------------> >>>>>> >>>>>> >>>>>> To reproduce: >>>>>> >>>>>> git clone https://github.com/intel/lkp-tests.git >>>>>> cd lkp-tests >>>>>> bin/lkp install job.yaml # job file is attached in this email >>>>>> bin/lkp run job.yaml >>>>>> >>>>>> ========================================================================================= >>>>>> compiler/cpufreq_governor/disk/filesize/fs2/fs/iterations/kconfig/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase: >>>>>> gcc-7/performance/1BRD_48G/4M/nfsv4/f2fs/1x/x86_64-rhel-7.2/1t/debian-x86_64-2016-08-31.cgz/fsyncBeforeClose/ivb44/40G/fsmark >>>>>> >>>>>> commit: >>>>>> c2993a1d7d ("nfsd4: extend reclaim period for reclaiming clients") >>>>>> 517dc52baa ("nfsd4: shortern default lease period") >>>>>> >>>>>> c2993a1d7d6687fd 517dc52baa2a508c82f68bbc72 >>>>>> ---------------- -------------------------- >>>>>> %stddev %change %stddev >>>>>> \ | \ >>>>>> 53.60 +32.4% 70.95 fsmark.files_per_sec >>>>>> 191.89 -24.4% 145.16 fsmark.time.elapsed_time >>>>>> 191.89 -24.4% 145.16 fsmark.time.elapsed_time.max >>>>> So what happened is the test took about 45 seconds less. >>>>> >>>>> I suspect you're starting the nfs server and then immediately running >>>>> this test. >>>> Yes. >>>> >>>>> The problem is that if there's a grace period on startup, any open will >>>>> just hang until the grace period ends. >>>>> >>>>> This patch changed the default grace period from 90 seconds to 45, so >>>>> that would explain the change. >>>>> >>>>> In my testing I usually >>>>> >>>>> start the nfs server >>>>> on the client: >>>>> mount the server >>>>> touch a file >>>>> >>>>> When the touch returns, I know any grace period has completed, and then >>>>> I can run any tests normally. >>> I've modified our test to touch a file before running the actual workload, then >>> requeue tests for both commit 517dc52baa and its parent c2993a1d7d, but the >>> result seems persistent which shows a ~30% improvement of fsmark.files_per_sec. >>> >> Any suggestions? > You're sure you only start timing after the "touch" returns? The result is normal after retesting, thank you for helping us improve the test. Best Regards, Rong, Chen > > --b. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LKP] [lkp-robot] [nfsd4] 517dc52baa: fsmark.files_per_sec 32.4% improvement 2018-08-07 5:02 ` Rong Chen @ 2018-08-07 14:16 ` J. Bruce Fields 0 siblings, 0 replies; 3+ messages in thread From: J. Bruce Fields @ 2018-08-07 14:16 UTC (permalink / raw) To: Rong Chen; +Cc: Ye Xiaolong, Stephen Rothwell, linux-nfs, lkp, LKML On Tue, Aug 07, 2018 at 01:02:16PM +0800, Rong Chen wrote: > > > On 08/01/2018 07:46 PM, J. Bruce Fields wrote: > > On Fri, Jul 27, 2018 at 08:22:25AM +0800, Ye Xiaolong wrote: > > > On 07/16, Ye Xiaolong wrote: > > > > On 07/04, Huang, Ying wrote: > > > > > "J. Bruce Fields" <bfields@redhat.com> writes: > > > > > > > > > > > Thanks! > > > > > > > > > > > > On Wed, Jun 20, 2018 at 02:52:43PM +0800, kernel test robot wrote: > > > > > > > FYI, we noticed a 32.4% improvement of fsmark.files_per_sec due to commit: > > > > > > > > > > > > > > > > > > > > > commit: 517dc52baa2a508c82f68bbc7219b48169e6b29f ("nfsd4: shortern default lease period") > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master > > > > > > That doesn't make any sense.... > > > > > > > > > > > > OK, I think I see the problem: > > > > > > > > > > > > > in testcase: fsmark > > > > > > > on test machine: 48 threads Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz with 64G memory > > > > > > > with following parameters: > > > > > > > > > > > > > > iterations: 1x > > > > > > > nr_threads: 1t > > > > > > > disk: 1BRD_48G > > > > > > > fs: f2fs > > > > > > > fs2: nfsv4 > > > > > > > filesize: 4M > > > > > > > test_size: 40G > > > > > > > sync_method: fsyncBeforeClose > > > > > > > cpufreq_governor: performance > > > > > > > > > > > > > > test-description: The fsmark is a file system benchmark to test synchronous write workloads, for example, mail servers workload. > > > > > > > test-url: https://sourceforge.net/projects/fsmark/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > Details are as below: > > > > > > > --------------------------------------------------------------------------------------------------> > > > > > > > > > > > > > > > > > > > > > To reproduce: > > > > > > > > > > > > > > git clone https://github.com/intel/lkp-tests.git > > > > > > > cd lkp-tests > > > > > > > bin/lkp install job.yaml # job file is attached in this email > > > > > > > bin/lkp run job.yaml > > > > > > > > > > > > > > ========================================================================================= > > > > > > > compiler/cpufreq_governor/disk/filesize/fs2/fs/iterations/kconfig/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase: > > > > > > > gcc-7/performance/1BRD_48G/4M/nfsv4/f2fs/1x/x86_64-rhel-7.2/1t/debian-x86_64-2016-08-31.cgz/fsyncBeforeClose/ivb44/40G/fsmark > > > > > > > > > > > > > > commit: > > > > > > > c2993a1d7d ("nfsd4: extend reclaim period for reclaiming clients") > > > > > > > 517dc52baa ("nfsd4: shortern default lease period") > > > > > > > > > > > > > > c2993a1d7d6687fd 517dc52baa2a508c82f68bbc72 > > > > > > > ---------------- -------------------------- > > > > > > > %stddev %change %stddev > > > > > > > \ | \ > > > > > > > 53.60 +32.4% 70.95 fsmark.files_per_sec > > > > > > > 191.89 -24.4% 145.16 fsmark.time.elapsed_time > > > > > > > 191.89 -24.4% 145.16 fsmark.time.elapsed_time.max > > > > > > So what happened is the test took about 45 seconds less. > > > > > > > > > > > > I suspect you're starting the nfs server and then immediately running > > > > > > this test. > > > > > Yes. > > > > > > > > > > > The problem is that if there's a grace period on startup, any open will > > > > > > just hang until the grace period ends. > > > > > > > > > > > > This patch changed the default grace period from 90 seconds to 45, so > > > > > > that would explain the change. > > > > > > > > > > > > In my testing I usually > > > > > > > > > > > > start the nfs server > > > > > > on the client: > > > > > > mount the server > > > > > > touch a file > > > > > > > > > > > > When the touch returns, I know any grace period has completed, and then > > > > > > I can run any tests normally. > > > > I've modified our test to touch a file before running the actual workload, then > > > > requeue tests for both commit 517dc52baa and its parent c2993a1d7d, but the > > > > result seems persistent which shows a ~30% improvement of fsmark.files_per_sec. > > > > > > > Any suggestions? > > You're sure you only start timing after the "touch" returns? > The result is normal after retesting, thank you for helping us improve the > test. Great, thanks for following up. --b. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-08-07 16:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20180620065243.GD11011@yexl-desktop>
[not found] ` <20180620154950.GA28475@parsley.fieldses.org>
[not found] ` <87va9vu21f.fsf@yhuang-dev.intel.com>
[not found] ` <20180716065500.GU27608@yexl-desktop>
[not found] ` <20180727002225.GF17169@yexl-desktop>
2018-08-01 11:46 ` [LKP] [lkp-robot] [nfsd4] 517dc52baa: fsmark.files_per_sec 32.4% improvement J. Bruce Fields
2018-08-07 5:02 ` Rong Chen
2018-08-07 14:16 ` J. Bruce Fields
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).