Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756616AbbGQAMN (ORCPT ); Thu, 16 Jul 2015 20:12:13 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:17516 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756149AbbGQAML (ORCPT ); Thu, 16 Jul 2015 20:12:11 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Thu, 16 Jul 2015 17:10:57 -0700 Message-ID: <55A8480C.6080806@nvidia.com> Date: Thu, 16 Jul 2015 17:10:52 -0700 From: Sai Gurrappadi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Morten Rasmussen , , CC: , , Dietmar Eggemann , , , , Juri Lelli , , , , Subject: Re: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement References: <1436293469-25707-1-git-send-email-morten.rasmussen@arm.com> <1436293469-25707-33-git-send-email-morten.rasmussen@arm.com> In-Reply-To: <1436293469-25707-33-git-send-email-morten.rasmussen@arm.com> X-NVConfidentiality: public Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.187.121] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL101.nvidia.com (172.20.187.10) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2868 Lines: 99 Hi Morten, On 07/07/2015 11:24 AM, Morten Rasmussen wrote: > --- > +static int energy_aware_wake_cpu(struct task_struct *p, int target) > +{ > + struct sched_domain *sd; > + struct sched_group *sg, *sg_target; > + int target_max_cap = INT_MAX; > + int target_cpu = task_cpu(p); > + int i; > + > + sd = rcu_dereference(per_cpu(sd_ea, task_cpu(p))); > + > + if (!sd) > + return target; > + > + sg = sd->groups; > + sg_target = sg; > + > + /* > + * Find group with sufficient capacity. We only get here if no cpu is > + * overutilized. We may end up overutilizing a cpu by adding the task, > + * but that should not be any worse than select_idle_sibling(). > + * load_balance() should sort it out later as we get above the tipping > + * point. > + */ > + do { > + /* Assuming all cpus are the same in group */ > + int max_cap_cpu = group_first_cpu(sg); > + > + /* > + * Assume smaller max capacity means more energy-efficient. > + * Ideally we should query the energy model for the right > + * answer but it easily ends up in an exhaustive search. > + */ > + if (capacity_of(max_cap_cpu) < target_max_cap && > + task_fits_capacity(p, max_cap_cpu)) { > + sg_target = sg; > + target_max_cap = capacity_of(max_cap_cpu); > + } > + } while (sg = sg->next, sg != sd->groups); Should be capacity_orig_of(max_cap_cpu) right? Might select a suboptimal sg_target if max_cap_cpu has a significant amount of IRQ/RT activity. > + > + /* Find cpu with sufficient capacity */ > + for_each_cpu_and(i, tsk_cpus_allowed(p), sched_group_cpus(sg_target)) { > + /* > + * p's blocked utilization is still accounted for on prev_cpu > + * so prev_cpu will receive a negative bias due the double > + * accouting. However, the blocked utilization may be zero. > + */ > + int new_usage = get_cpu_usage(i) + task_utilization(p); > + > + if (new_usage > capacity_orig_of(i)) > + continue; Is this supposed to be capacity_of(i) instead? > + > + if (new_usage < capacity_curr_of(i)) { > + target_cpu = i; > + if (cpu_rq(i)->nr_running) > + break; > + } > + > + /* cpu has capacity at higher OPP, keep it as fallback */ > + if (target_cpu == task_cpu(p)) > + target_cpu = i; > + } > + > + if (target_cpu != task_cpu(p)) { > + struct energy_env eenv = { > + .usage_delta = task_utilization(p), > + .src_cpu = task_cpu(p), > + .dst_cpu = target_cpu, > + }; > + > + /* Not enough spare capacity on previous cpu */ > + if (cpu_overutilized(task_cpu(p))) > + return target_cpu; > + > + if (energy_diff(&eenv) >= 0) > + return task_cpu(p); > + } > + > + return target_cpu; > +} > + -Sai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/