From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753133AbcHOPaF (ORCPT ); Mon, 15 Aug 2016 11:30:05 -0400 Received: from foss.arm.com ([217.140.101.70]:41419 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752590AbcHOPaD (ORCPT ); Mon, 15 Aug 2016 11:30:03 -0400 Date: Mon, 15 Aug 2016 16:30:04 +0100 From: Morten Rasmussen To: Peter Zijlstra Cc: mingo@redhat.com, dietmar.eggemann@arm.com, yuyang.du@intel.com, vincent.guittot@linaro.org, mgalbraith@suse.de, sgurrappadi@nvidia.com, freedom.tan@mediatek.com, keita.kobayashi.ym@renesas.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 09/13] sched/fair: Let asymmetric cpu configurations balance at wake-up Message-ID: <20160815153003.GD3391@e105550-lin.cambridge.arm.com> References: <1469453670-2660-1-git-send-email-morten.rasmussen@arm.com> <1469453670-2660-10-git-send-email-morten.rasmussen@arm.com> <20160815133949.GT6879@twins.programming.kicks-ass.net> <20160815150132.GC3391@e105550-lin.cambridge.arm.com> <20160815151006.GD30192@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160815151006.GD30192@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 15, 2016 at 05:10:06PM +0200, Peter Zijlstra wrote: > On Mon, Aug 15, 2016 at 04:01:34PM +0100, Morten Rasmussen wrote: > > On Mon, Aug 15, 2016 at 03:39:49PM +0200, Peter Zijlstra wrote: > > > > +static int wake_cap(struct task_struct *p, int cpu, int prev_cpu) > > > > +{ > > > > + long min_cap, max_cap; > > > > + > > > > + min_cap = min(capacity_orig_of(prev_cpu), capacity_orig_of(cpu)); > > > > + max_cap = cpu_rq(cpu)->rd->max_cpu_capacity; > > > > > > There's a tiny hole here, which I'm fairly sure we don't care about. If > > > @p last ran on @prev_cpu before @prev_cpu was split from @rd this > > > doesn't 'work' right. > > > > I hadn't considered that. What is 'working right' in this scenario? > > Ignoring @prev_cpu as it isn't a valid option anymore? > > Probably, yeah. > > > In that case, since @prev_cpu is only used as part the min() it should > > only cause min_cap to be potentially smaller than it should be, not > > larger. It could lead us to let BALANCE_WAKE take over in scenarios > > where select_idle_sibling() would have been sufficient, but it should > > harm. > > +not, right? Yes :) > > > However, as you say, I'm not sure if we care that much. > > Yeah, don't think so, its extremely unlikely to happen, almost nobody > mucks about with root_domains anyway. And those that do, do so once to > setup things and then leave them be. > > > Talking about @rd, I discussed with Juri and Dietmar the other week > > whether the root_domain is RCU protected, and if we therefore have to > > move the call to wake_cap() after the rcu_read_lock() below. I haven't > > yet done thorough investigation to find the answer. Should it be > > protected? > > Yeah, I think either RCU or RCU-sched, I forever forget. Okay. Should I send an updated version?