Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756954AbcK2Lm7 (ORCPT ); Tue, 29 Nov 2016 06:42:59 -0500 Received: from merlin.infradead.org ([205.233.59.134]:38964 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754349AbcK2Lmx (ORCPT ); Tue, 29 Nov 2016 06:42:53 -0500 Date: Tue, 29 Nov 2016 12:42:43 +0100 From: Peter Zijlstra To: Morten Rasmussen Cc: Vincent Guittot , mingo@kernel.org, linux-kernel@vger.kernel.org, matt@codeblueprint.co.uk, dietmar.eggemann@arm.com, kernellwp@gmail.com, yuyang.du@intel.com, umgwanakikbuti@gmail.com Subject: Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork Message-ID: <20161129114243.GF3092@twins.programming.kicks-ass.net> References: <1480088073-11642-1-git-send-email-vincent.guittot@linaro.org> <1480088073-11642-2-git-send-email-vincent.guittot@linaro.org> <20161129105758.GA1716@e105550-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161129105758.GA1716@e105550-lin.cambridge.arm.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1068 Lines: 29 On Tue, Nov 29, 2016 at 10:57:59AM +0000, Morten Rasmussen wrote: > > @@ -5708,13 +5708,6 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t > > > > avg_cost = this_sd->avg_scan_cost; > > > > - /* > > - * Due to large variance we need a large fuzz factor; hackbench in > > - * particularly is sensitive here. > > - */ > > - if ((avg_idle / 512) < avg_cost) > > - return -1; > > - > > time = local_clock(); > > > > for_each_cpu_wrap(cpu, sched_domain_span(sd), target, wrap) { > > I don't quite get this fix, but it is very likely because I haven't paid > enough attention. > > Are you saying that removing the avg_cost check is improving hackbench > performance? I thought it was supposed to help hackbench? I'm confused > :-( IIRC, and my pounding head really doesn't remember much, the comment reads like we need the large fudge factor because hackbench. That is, hackbench would like this test to go away, but others benchmarks will tank. Now, if only I would've written down which benchmarks that were.. awell.