From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751446AbbI2X2S (ORCPT <rfc822;w@1wt.eu>);
	Tue, 29 Sep 2015 19:28:18 -0400
Received: from mga03.intel.com ([134.134.136.65]:6928 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751115AbbI2X2Q (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 29 Sep 2015 19:28:16 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.17,609,1437462000"; 
   d="scan'208";a="570875341"
From: "Huang\, Ying" <ying.huang@linux.intel.com>
To: Jeff Layton <jeff.layton@primarydata.com>
Cc: kernel test robot <ying.huang@intel.com>, <lkp@01.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [lkp] [nfsd] 4aac1bf05b: -2.9% fsmark.files_per_sec
References: <87h9mfhwcj.fsf@yhuang-dev.intel.com>
	<20150929074151.0fe32fc9@tlielax.poochiereds.net>
Date: Wed, 30 Sep 2015 07:27:54 +0800
In-Reply-To: <20150929074151.0fe32fc9@tlielax.poochiereds.net> (Jeff Layton's
	message of "Tue, 29 Sep 2015 07:41:51 -0400")
Message-ID: <87lhbokdqd.fsf@yhuang-dev.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Jeff Layton <jeff.layton@primarydata.com> writes:

> On Mon, 28 Sep 2015 14:49:32 +0800
> kernel test robot <ying.huang@intel.com> wrote:
>
>> FYI, we noticed the below changes on
>> 
>> =========================================================================================
>> tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/iterations/nr_threads/disk/fs/fs2/filesize/test_size/sync_method/nr_directories/nr_files_per_directory:
>>   lkp-ne04/fsmark/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/1x/32t/1HDD/xfs/nfsv4/5K/400M/fsyncBeforeClose/16d/256fpd
>> 
>> commit: 
>>   cd2d35ff27c4fda9ba73b0aa84313e8e20ce4d2c
>>   4aac1bf05b053a201a4b392dd9a684fb2b7e6103
>> 
>
> A question...
>
> I think my tree should now contain a fix for this, but with a
> performance regression like this it's difficult to know for sure.
>
> Is there some (automated) way to request that the KTR redo this test?
> If not, will I get a note saying "problem seems to now be fixed" or do
> I just take a lack of further emails from the KTR about this as a sign
> that it's resolved?

Can you provide the branch name and commit ID for your tree with fix?  I
can confirm whether it is fixed for you.

Best Regards,
Huang, Ying