Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp296162ybl; Wed, 29 Jan 2020 00:17:57 -0800 (PST) X-Google-Smtp-Source: APXvYqyRI1j8d47WBDsjTomqcWD4l7KLohmIMDTkjUgv1hCrOViorSM2SUK4/p4KgCk3QQF0uRGH X-Received: by 2002:a9d:5885:: with SMTP id x5mr19131558otg.132.1580285877327; Wed, 29 Jan 2020 00:17:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580285877; cv=none; d=google.com; s=arc-20160816; b=B7yrOnqXTunsWPbwzal/geyFI6U/r9aT9nVQB8K4v88T8zb+BWOZ3K9Lmm4IUTcyZn mvMbbB9FTx2HfvGGQEiGRrm078o1r3TxrrSCj+8nez325a7OEH6AidEAn784H5B+58FU F6Am0jFlA97fc0+92leEx1b0QyvdHSwy/ZxY+5bfiwWhuAofsEAcWlO8Zn1dOKmxMOXK jhj5uyGMOtPWrCbvEwbxRtpURoDugjHJ2p/EfmShKkaKB7Al43ZQ2kpyokhkBWhBR17+ 8M8jyzGq7LUWbRqrSv3SbX8SF1gxjqd/S6J/GGg13g/Mwufrop0VsIsw7LIOeDsm+04/ k55g== 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; bh=bcqadX3AtypamvOSD4XlPVCdtC0ygaV5HxFkT0WHIcE=; b=f3XFSb0NHdH3dSHXJimNGyyDNUJgN/yPCTkGdy0FHmn3EYbgRooTFoyURjVkYe1dg0 TsbUDs8soPXiACVX77QY+QWeUFZ0DXa4SQqu7plamfcBVvR+Yqz9psBKkMcCYbAJPqKI lO+YKM+BDmoJrgEcnK6hRN+jFotm41710OOfaPQnNqj1whanO2l3+0XDWkhFOrbmK3ob ynXb9ObUvQjjiT9JWOfHbculwyhnTLFokbtVybm5bYhUbckNcAy5nqqV6655Umnocnyy uWV64iQz+UNL3q38Fv2y3kvRAnFDOTwe9nkkh0M1uJx8Ozy1HoTPPQlSZoasO7a4zNHQ IasA== 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 d197si670569oig.115.2020.01.29.00.17.43; Wed, 29 Jan 2020 00:17:57 -0800 (PST) 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 S1726157AbgA2IQl (ORCPT + 99 others); Wed, 29 Jan 2020 03:16:41 -0500 Received: from foss.arm.com ([217.140.110.172]:37986 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726116AbgA2IQl (ORCPT ); Wed, 29 Jan 2020 03:16:41 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3264F328; Wed, 29 Jan 2020 00:16:40 -0800 (PST) Received: from e107158-lin (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2FC113F52E; Wed, 29 Jan 2020 00:20:16 -0800 (PST) Date: Wed, 29 Jan 2020 08:16:36 +0000 From: Qais Yousef To: Pavan Kondeti Cc: Valentin Schneider , linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, morten.rasmussen@arm.com, qperret@google.com, adharmap@codeaurora.org Subject: Re: [PATCH v3 1/3] sched/fair: Add asymmetric CPU capacity wakeup scan Message-ID: <20200129081633.3ezb7ucq5kkojkhg@e107158-lin> References: <20200126200934.18712-1-valentin.schneider@arm.com> <20200126200934.18712-2-valentin.schneider@arm.com> <20200128062245.GA27398@codeaurora.org> <1ed322d6-0325-ecac-cc68-326a14b8c1dd@arm.com> <20200129035258.GB27398@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200129035258.GB27398@codeaurora.org> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/29/20 09:22, Pavan Kondeti wrote: > On Tue, Jan 28, 2020 at 11:30:26AM +0000, Valentin Schneider wrote: > > Hi Pavan, > > > > On 28/01/2020 06:22, Pavan Kondeti wrote: > > > Hi Valentin, > > > > > > On Sun, Jan 26, 2020 at 08:09:32PM +0000, Valentin Schneider wrote: > > >> > > >> +static inline int check_cpu_capacity(struct rq *rq, struct sched_domain *sd); > > >> + > > >> +/* > > >> + * Scan the asym_capacity domain for idle CPUs; pick the first idle one on which > > >> + * the task fits. If no CPU is big enough, but there are idle ones, try to > > >> + * maximize capacity. > > >> + */ > > >> +static int select_idle_capacity(struct task_struct *p, int target) > > >> +{ > > >> + unsigned long best_cap = 0; > > >> + struct sched_domain *sd; > > >> + struct cpumask *cpus; > > >> + int best_cpu = -1; > > >> + struct rq *rq; > > >> + int cpu; > > >> + > > >> + if (!static_branch_unlikely(&sched_asym_cpucapacity)) > > >> + return -1; > > >> + > > >> + sd = rcu_dereference(per_cpu(sd_asym_cpucapacity, target)); > > >> + if (!sd) > > >> + return -1; > > >> + > > >> + sync_entity_load_avg(&p->se); > > >> + > > >> + cpus = this_cpu_cpumask_var_ptr(select_idle_mask); > > >> + cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr); > > >> + > > >> + for_each_cpu_wrap(cpu, cpus, target) { > > >> + rq = cpu_rq(cpu); > > >> + > > >> + if (!available_idle_cpu(cpu)) > > >> + continue; > > >> + if (task_fits_capacity(p, rq->cpu_capacity)) > > >> + return cpu; > > > > > > I have couple of questions. > > > > > > (1) Any particular reason for not checking sched_idle_cpu() as a backup > > > for the case where all eligible CPUs are busy? select_idle_cpu() does > > > that. > > > > > > > No particular reason other than we didn't consider it, I think. I don't see > > any harm in folding it in, I'll do that for v4. I am curious however; are > > you folks making use of SCHED_IDLE? AFAIA Android isn't making use of it > > yet, though Viresh paved the way for that to happen. > > > > We are not using SCHED_IDLE in product setups. I am told Android may use it > for background tasks in future. I am not completely sure though. I asked it > because select_idle_cpu() is using it. I believe Viresh intention when he pushed for the support was allowing this use case. FWIW, I had a patch locally to implement this but waiting on latency_nice attribute to go in [1] before I attempt to upstream it. The design goals I had in mind: 1. If there are multiple energy efficient CPUs we can select, select the idle one. 2. If latency nice is set and the most energy efficient CPU is not idle, then fallback to the most energy efficient idle CPU. Android use case needs EAS path support before it can be useful to it. [1] https://lore.kernel.org/lkml/20190919144259.vpuv7hvtqon4qgrv@e107158-lin.cambridge.arm.com/ -- Qais Yousef