From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161869AbcFGQtw (ORCPT ); Tue, 7 Jun 2016 12:49:52 -0400 Received: from foss.arm.com ([217.140.101.70]:46680 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161164AbcFGQtv (ORCPT ); Tue, 7 Jun 2016 12:49:51 -0400 Date: Tue, 7 Jun 2016 17:50:46 +0100 From: Morten Rasmussen To: Vincent Guittot Cc: Peter Zijlstra , "mingo@redhat.com" , Dietmar Eggemann , Yuyang Du , mgalbraith@suse.de, linux-kernel Subject: Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations Message-ID: <20160607165045.GC9187@e105550-lin.cambridge.arm.com> References: <20160524102928.GF27946@e105550-lin.cambridge.arm.com> <20160524131610.GG27946@e105550-lin.cambridge.arm.com> <20160524133642.GH27946@e105550-lin.cambridge.arm.com> <20160524150204.GI27946@e105550-lin.cambridge.arm.com> <20160525091200.GJ27946@e105550-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu, May 26, 2016 at 08:45:03AM +0200, Vincent Guittot wrote: > On 25 May 2016 at 11:12, Morten Rasmussen wrote: > > On Tue, May 24, 2016 at 05:53:27PM +0200, Vincent Guittot wrote: > >> On 24 May 2016 at 17:02, Morten Rasmussen wrote: > >> > On Tue, May 24, 2016 at 03:52:00PM +0200, Vincent Guittot wrote: > >> >> On 24 May 2016 at 15:36, Morten Rasmussen wrote: > >> >> > On Tue, May 24, 2016 at 03:27:05PM +0200, Vincent Guittot wrote: > >> >> >> On 24 May 2016 at 15:16, Morten Rasmussen wrote: > >> >> >> > On Tue, May 24, 2016 at 02:12:38PM +0200, Vincent Guittot wrote: > >> >> >> >> On 24 May 2016 at 12:29, Morten Rasmussen wrote: > > [snip] > > >> >> > It is not clear to me what the other cases are. What kind of cases do > >> >> > you have in mind? > >> >> > >> >> As an example, you have a task A that have to be on a big CPU because > >> >> of the requirement of compute capacity, that wakes up a task B that > >> >> can run on any cpu according to its utilization. The fast wake up path > >> >> is fine for task B whatever prev cpu is. > >> > > >> > In that case, we will take always take fast path (select_idle_sibling()) > >> > for task B if wake_wide() allows it, which should be fine. > >> > >> Even if want_affine is set, the wake up of task B will not use the fast path. > >> The affine_sd will not be set because the sched_domain, which have > >> both cpus, will not have the SD_WAKE_AFFINE flag according to this > >> patch, isn't it ? > >> So task B can't use the fast path whereas nothing prevent him to take > >> benefit of it > >> > >> Am I missing something ? > > > > No, I think you are right. Very good point. The cpumask test with > > sched_domain_span() will of cause return false. So yes, in this case the > > slow path is taken. It isn't wrong as such, just slower for asymmetric > > capacity systems :-) > > > > So, I still don't see why the function wake_cap that is introduce by > patch 9 can't be used for testing cross capacity migration at wake up > ? > The only reason for which we would like to skip fast wake up path for > cross capacity migration, is whether the task needs more capacity than > the capacity of cpu or prev_cpu. You already do that for prev_cpu, > can't you add same test for cpu ? I think I finally see what you mean. Thanks for your patience :-) It should be safe to let wake_affine be cross-capacity as long as we only take the fast path when both prev_cpu and this_cpu have sufficient capacity for the task. select_idle_sibling() can never end up looking at cpus with different capacities than those of this_cpu and prev_cpu. I will give that a try. I have a few ideas on how it can extended to use the fast path in a few additional cases as well.