From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D990C28CF6 for ; Wed, 1 Aug 2018 11:47:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 40CCF208A4 for ; Wed, 1 Aug 2018 11:47:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40CCF208A4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389040AbeHANc6 (ORCPT ); Wed, 1 Aug 2018 09:32:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36626 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387654AbeHANc5 (ORCPT ); Wed, 1 Aug 2018 09:32:57 -0400 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3BE8430E684A; Wed, 1 Aug 2018 11:47:01 +0000 (UTC) Received: from parsley.fieldses.org (ovpn-116-121.phx2.redhat.com [10.3.116.121]) by smtp.corp.redhat.com (Postfix) with ESMTP id E46B52010CDA; Wed, 1 Aug 2018 11:46:57 +0000 (UTC) Received: by parsley.fieldses.org (Postfix, from userid 2815) id E3D8B1801FA; Wed, 1 Aug 2018 07:46:47 -0400 (EDT) Date: Wed, 1 Aug 2018 07:46:47 -0400 From: "J. Bruce Fields" To: Ye Xiaolong Cc: Stephen Rothwell , linux-nfs@vger.kernel.org, lkp@01.org, LKML , "Chen, Rong A" Subject: Re: [LKP] [lkp-robot] [nfsd4] 517dc52baa: fsmark.files_per_sec 32.4% improvement Message-ID: <20180801114642.GA21500@parsley.fieldses.org> References: <20180620065243.GD11011@yexl-desktop> <20180620154950.GA28475@parsley.fieldses.org> <87va9vu21f.fsf@yhuang-dev.intel.com> <20180716065500.GU27608@yexl-desktop> <20180727002225.GF17169@yexl-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180727002225.GF17169@yexl-desktop> User-Agent: Mutt/1.10.0 (2018-05-17) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.25 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Wed, 01 Aug 2018 11:47:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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" 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.