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 S1751788AbcFBA2T (ORCPT <rfc822;w@1wt.eu>);
	Wed, 1 Jun 2016 20:28:19 -0400
Received: from mga03.intel.com ([134.134.136.65]:53576 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751464AbcFBA2R (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 1 Jun 2016 20:28:17 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,403,1459839600"; 
   d="scan'208";a="712516888"
From: "Huang\, Ying" <ying.huang@intel.com>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: "Huang\, Ying" <ying.huang@intel.com>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        <lkp@01.org>, <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Linus Torvalds" <torvalds@linux-foundation.org>,
        Xiaolong Ye <xiaolong.ye@intel.com>
Subject: Re: [LKP] [lkp] [sched/fair] 53d3bc773e: hackbench.throughput -32.9% regression
References: <87inxud4ex.fsf@yhuang-dev.intel.com>
	<87eg8id3s3.fsf@yhuang-dev.intel.com>
	<20160531124151.GK3190@twins.programming.kicks-ass.net>
	<87eg8h8pwl.fsf@yhuang-dev.intel.com>
	<20160601084035.GL3190@twins.programming.kicks-ass.net>
	<87inxtjnnb.fsf@yhuang-dev.intel.com>
	<1464774513.4023.78.camel@gmail.com>
Date: Thu, 02 Jun 2016 08:28:14 +0800
In-Reply-To: <1464774513.4023.78.camel@gmail.com> (Mike Galbraith's message of
	"Wed, 1 Jun 2016 11:48:33 +0200")
Message-ID: <87pos0igdd.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

Mike Galbraith <umgwanakikbuti@gmail.com> writes:

> On Wed, 2016-06-01 at 16:53 +0800, Huang, Ying wrote:
>
>> You mean the commit is a functionality fix?
>
> Yup.
>
> These kind of things can be a bit annoying.  The fix to not subtract
> load that we never added in the first place also pushed hackbench
> around a bit.  Do anything at all with load_avg, you're gonna push
> this/that benchmark around a bit, and folks who watch numbers closely
> can end up chasing meaningless deltas.

If this report annoyed you, I am sorry about that.  We just want to be
helpful via providing some information.  Now I know hackbench is
sensitive to load_avg changes, thanks a lot for the information.

Best Regards,
Huang, Ying