From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752344AbcEZGp1 (ORCPT ); Thu, 26 May 2016 02:45:27 -0400 Received: from mail-lf0-f47.google.com ([209.85.215.47]:35279 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbcEZGpZ (ORCPT ); Thu, 26 May 2016 02:45:25 -0400 MIME-Version: 1.0 In-Reply-To: <20160525091200.GJ27946@e105550-lin.cambridge.arm.com> References: <1464001138-25063-7-git-send-email-morten.rasmussen@arm.com> <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> From: Vincent Guittot Date: Thu, 26 May 2016 08:45:03 +0200 Message-ID: Subject: Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations To: Morten Rasmussen Cc: Peter Zijlstra , "mingo@redhat.com" , Dietmar Eggemann , Yuyang Du , mgalbraith@suse.de, linux-kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ? > It is clearly not as optimized for asymmetric capacity systems as it > could be, but my focus was to not ruin existing behaviour and minimize > overhead for others. There are a lot of different routes through those > conditions in the first half of select_task_rq_fair() that aren't > obvious. I worry that some users depend on them and that I don't > see/understand all of them. > > If people agree on changing things, it is fine with me. I just tried to > avoid getting the patches shot down on that account ;-)