Received: by 10.213.65.68 with SMTP id h4csp906859imn; Thu, 22 Mar 2018 11:07:47 -0700 (PDT) X-Google-Smtp-Source: AG47ELtLPtmFKF8Abro4M6lWVsxMgYgOa5ZUiNk9b1ljspKB/Ac+g/h/dcXMVLuIHy6fyiK1N6XG X-Received: by 2002:a17:902:988c:: with SMTP id s12-v6mr10757274plp.318.1521742067918; Thu, 22 Mar 2018 11:07:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521742067; cv=none; d=google.com; s=arc-20160816; b=r93h3/tmDqTHhREz3fKXsr0vvghcPfGu38ZWQpZ6ZUbo6Io4JN0uktIYJ1pCul855P Sr7bw9oncp6Yq7JaBP6AkO8iLLFLjjaVRXLiZd4q+nWPcs0gbxsjCk5KECtljcoHqCCf sr7gmLzIwnyV5unNZjW7HXLEBq9F32i/1sUllVuCIw0haYNojcBCm0OCILceVDAD9od/ LgnVU6WILeelvcECwZ7mCqF/MB4vg2h4tEcizRy+DvAMLaLgGikK4+avN/zG5BSRhlLr jYUD9u8Yg5Fa8/WDcB1X70wdKmfX/0zWP3v6Owp1rbYYBngKsa1UEbHCNkVav8h3ttH2 +qkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=DMKNGhmEKUk0OxbmXYQ8ekIiFo1ENkm5uUiZb6l0J90=; b=p4EM6UBQaOiDE3qYXK3CQN7DXxcwoKKMI7KWh/PSDp3z/ULhj1cKXm0BGbU5tcuz4J IKdJIUDnxz2D+TydCFY1LrM0K2Uz+1sR9AK68vtNqUtUgg8Ki+oiF2UISvZqmt3NOJWJ wjNtBQYgzhoAIExLgfNtl6G9zrhgvB0uKqUl0YOqbFTeIOWqoRWpdi84S5FG+4Jrfp73 ML8WAU4ByCgWjdifiAhtdqYK1vcIhGTZyPXwzdD7AQAP5AqeLsIpvuhqKMKJ987eVLaX +y2dmalnGsliQ0+17Iy69CpJVRBXxE1IjHkRJJMipNdqlTzrRZg9IMexzUVoe58qrbNO /+Cg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p7si4710122pgq.8.2018.03.22.11.07.31; Thu, 22 Mar 2018 11:07:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751888AbeCVSGa (ORCPT + 99 others); Thu, 22 Mar 2018 14:06:30 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:41118 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595AbeCVSG2 (ORCPT ); Thu, 22 Mar 2018 14:06:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6AAA41529; Thu, 22 Mar 2018 11:06:28 -0700 (PDT) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E38263F487; Thu, 22 Mar 2018 11:06:25 -0700 (PDT) Date: Thu, 22 Mar 2018 18:06:23 +0000 From: Patrick Bellasi To: Joel Fernandes Cc: Dietmar Eggemann , LKML , Peter Zijlstra , Quentin Perret , Thara Gopinath , Linux PM , Morten Rasmussen , Chris Redpath , Valentin Schneider , "Rafael J . Wysocki" , Greg Kroah-Hartman , Vincent Guittot , Viresh Kumar , Todd Kjos Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up Message-ID: <20180322180623.GE13951@e110439-lin> References: <20180320094312.24081-1-dietmar.eggemann@arm.com> <20180320094312.24081-6-dietmar.eggemann@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22-Mar 09:27, Joel Fernandes wrote: > Hi, > > On Tue, Mar 20, 2018 at 2:43 AM, Dietmar Eggemann > wrote: > > > > From: Quentin Perret [...] > > +static inline bool wake_energy(struct task_struct *p, int prev_cpu) > > +{ > > + struct sched_domain *sd; > > + > > + if (!static_branch_unlikely(&sched_energy_present)) > > + return false; > > + > > + sd = rcu_dereference_sched(cpu_rq(prev_cpu)->sd); > > + if (!sd || sd_overutilized(sd)) > > Shouldn't you check for the SD_ASYM_CPUCAPACITY flag here? I think that should be already covered by the static key check above... > > > + return false; > > + > > + return true; > > +} > > + > > /* > > * select_task_rq_fair: Select target runqueue for the waking task in domains > > * that have the 'sd_flag' flag set. In practice, this is SD_BALANCE_WAKE, > > @@ -6529,18 +6583,22 @@ static int > > select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_flags) > > { > > struct sched_domain *tmp, *affine_sd = NULL, *sd = NULL; > > + struct sched_domain *energy_sd = NULL; > > int cpu = smp_processor_id(); > > int new_cpu = prev_cpu; > > - int want_affine = 0; > > + int want_affine = 0, want_energy = 0; > > int sync = (wake_flags & WF_SYNC) && !(current->flags & PF_EXITING); > > > > + rcu_read_lock(); > > + > > if (sd_flag & SD_BALANCE_WAKE) { > > record_wakee(p); > > + want_energy = wake_energy(p, prev_cpu); > > want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu) > > - && cpumask_test_cpu(cpu, &p->cpus_allowed); > > + && cpumask_test_cpu(cpu, &p->cpus_allowed) > > + && !want_energy; > > } > > > > - rcu_read_lock(); > > for_each_domain(cpu, tmp) { > > if (!(tmp->flags & SD_LOAD_BALANCE)) > > break; > > @@ -6555,6 +6613,14 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f > > break; > > } > > > > + /* > > + * Energy-aware task placement is performed on the highest > > + * non-overutilized domain spanning over cpu and prev_cpu. > > + */ > > + if (want_energy && !sd_overutilized(tmp) && > > + cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) > > Shouldn't you check for the SD_ASYM_CPUCAPACITY flag here for tmp level? ... and this then should be covered by the previous check in wake_energy(), which sets want_energy. > > > + energy_sd = tmp; > > + > > if (tmp->flags & sd_flag) > > sd = tmp; > > else if (!want_affine) > > @@ -6586,6 +6652,8 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f > > if (want_affine) > > current->recent_used_cpu = cpu; > > } > > + } else if (energy_sd) { > > + new_cpu = find_energy_efficient_cpu(energy_sd, p, prev_cpu); > > Even if want_affine = 0 (want_energy = 1), we can have sd = NULL if > sd_flag and tmp->flags don't match. In this case we wont enter the EAS > selection path because sd will be = NULL. So should you be setting sd > = NULL explicitly if energy_sd != NULL , or rather do the if > (energy_sd) before doing the if (!sd) ? That's the same think I was also proposing in my reply to this patch. But in my case the point was mainly to make the code easier to follow... which at the end it's also to void all the consideration on dependencies you describe above. Joel, can you have a look at what I proposed... I was not entirely sure that we miss some code paths doing it that way. > If you still want to keep the logic this way, then probably you should > also check if (tmp->flags & sd_flag) == true in the loop? That way > energy_sd wont be set at all (Since we're basically saying we dont > want to do wake up across this sd (in energy aware fashion in this > case) if the domain flags don't watch the wake up sd_flag. > > thanks, > > - Joel -- #include Patrick Bellasi