Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp1284528iof; Tue, 7 Jun 2022 02:28:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy6ZcPFiamJRUJ9GlVbuuiced9V2wJhfmTMfRlMa/gPgle0ARznQsgCD6zwgdhxbqVhJc6M X-Received: by 2002:a17:90b:1e46:b0:1e6:826e:73ea with SMTP id pi6-20020a17090b1e4600b001e6826e73eamr30685206pjb.68.1654594128062; Tue, 07 Jun 2022 02:28:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654594128; cv=none; d=google.com; s=arc-20160816; b=VkJKlHmJAd3YmITNYWyfRz6EtgYuXFHfyW9hmhTI3ddbViGQej3TMKqYR3v6xAi3f+ SGafG7yNU5p5b8gTBedfoP93un/zxlg9xJ5To4xfgZCn26AWCxhNUm9FUHUodBjO1J6V i6FJd/IvgNBNwScDfJhZY4g0yfcVJpUsdzU/yodDy1a1aSF+EXOvUaNkTxDJWByZz11U lyn3NhDV7zjMNJ4/WJh0LIAFRty2AhWx7+4Hu+PPHYkhO/mdyT1+3Zv8t+9OdhKUtO++ cSO5+p0a31X55HzDwitqEe34nQKo9Qs80LxNx3Rzx8exTENen1lQ0gRTk7Dul/Q2JDgo y8Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=j0Wwqj0q0gz7akdNJ/mCyQgDbF5i0epVi6uOBkYKKA4=; b=A+yJwpcOEOV1uXcE6hIl2w2Tb/nTYvt/3jgEMwMeNVXNDzPsuyOeeiv8fLQC29zSv5 yoPXowemJesM59dIoQU4kibllEkIUQ5mG2kp61kdYL25Vmp5J6Zb4QPHZ0jDscEqZAQ+ ow/1bXUjOztVxw/m4pWSUZLThFiQ+87iHcsyg0aRiBBIAHoIujURYI53cdj16cPEPymE +/qKdoyXdgzzeslHZreB/G+PJ6cWgfJFlNHAyrVBp/Pgct+qlZedhmHDD9FdDU/C/u6I 3/szZWpUECTPLbz3CUzvN4d4HpBbTFoIEw1wgdK4rHY1HJPYSmh6qyp0e7vnsDunho2h 0d3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jl8zwanv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id il16-20020a17090b165000b001dc3db49225si27599239pjb.114.2022.06.07.02.28.32; Tue, 07 Jun 2022 02:28:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jl8zwanv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237387AbiFGHAN (ORCPT + 99 others); Tue, 7 Jun 2022 03:00:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237399AbiFGHAE (ORCPT ); Tue, 7 Jun 2022 03:00:04 -0400 Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD7EBE274E for ; Tue, 7 Jun 2022 00:00:02 -0700 (PDT) Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-30fdbe7467cso130086267b3.1 for ; Tue, 07 Jun 2022 00:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j0Wwqj0q0gz7akdNJ/mCyQgDbF5i0epVi6uOBkYKKA4=; b=jl8zwanvnIbT7jXgIxjYYkcfSXe365gZdAkgVrAIeKNohsRMzBjqxG1kLh83J6ckcR t8rslBph93nZ/xFZc8qEc8LT+UvMnkw9KR2e7jkyQFLICVQ4TG5feXsD+ru1MojTy/zC ZAmFhDujfBelHN65KDbjDx0zYdOwmLPTVXhwNgdnsmftaSXpBBsKSj4cJIAxdgumnm2p tHkMIBiQ15r+LyGM3rUucVtfMeCmet6JZ20+vnRr9NHSpr23vHVzOZ23gclrY6dEyGHG KWHjjz63JU8ZqcUiQVnToBlPnamSofIBGtfLEyIHTBmnKFQwwpdwPbcgZhJeQgo9vyyR lfWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j0Wwqj0q0gz7akdNJ/mCyQgDbF5i0epVi6uOBkYKKA4=; b=xsJ7Y9tRVtvuRiFWIPyZA4Hoj5C3VSsEfljaAmbrM8GPrM76sikGAE1MZWQrPTNUIz XCSGxtovJIxM/OxRnVbje9VjFU3B5Pb76eVveRd52eWCwjo9nhHYwO/9vdw+pUGrZtjO qOfQ9KAd2IHUxayPUxvC7w89t9kTOF2rPLLyHrkv+rPqy0aGzcOacWbpQZlFHSKYhEnq OFa8CTicDkQGVVa2kDWP0yDq4WhXZSQ2ZqGHGvOpIMyJjiF2zglB9oTgg2ak8981uJ2B TSsPvS/2wo6OJ11g9uV34ylptccp5CARxdsRAQ8d48Lj1fTBulSI7vToYEoNC6fOvRrZ Jfew== X-Gm-Message-State: AOAM532pODfJkx/oqbJVgpcW+3aCDn/9qhvLe6SfTTD4Njkgg4gNjLB4 ZyYYuguSppxY1Ga3YM/ljZUpCZiC0s/zGrpO4Mv1QvEyU34= X-Received: by 2002:a81:f15:0:b0:30c:9e77:e6fa with SMTP id 21-20020a810f15000000b0030c9e77e6famr30723403ywp.248.1654585201996; Tue, 07 Jun 2022 00:00:01 -0700 (PDT) MIME-Version: 1.0 References: <20220523155140.2878563-1-vdonnefort@google.com> <20220523155140.2878563-7-vdonnefort@google.com> In-Reply-To: From: Vincent Guittot Date: Tue, 7 Jun 2022 08:59:50 +0200 Message-ID: Subject: Re: [PATCH v9 6/7] sched/fair: Remove task_util from effective utilization in feec() To: Vincent Donnefort Cc: peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com, morten.rasmussen@arm.com, chris.redpath@arm.com, qperret@google.com, tao.zhou@linux.dev, kernel-team@android.com, Vincent Donnefort Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 6 Jun 2022 at 11:41, Vincent Donnefort wrote: > > [...] > > > > + > > > +/* > > > + * compute_energy(): Use the Energy Model to estimate the energy that @pd would > > > + * consume for a given utilization landscape @eenv. If @dst_cpu < 0 the task > > > > I find this comment a bit confusing because compute_energy() adds the > > task contribution if dst_cpu >= 0 but doesn't remove it. The fact that > > eenv->pd_busy_time has been previously computed without the > > contribution of the task, is outside the scope of this this function > > whereas the comment suggest that the remove will happen in > > compute_energy() > > Arg, leftover from a previous version where this function was adding or removing > the contribution. I'll update! > > > > > > + * contribution is removed from the energy estimation. > > > + */ > > > +static inline unsigned long > > > +compute_energy(struct energy_env *eenv, struct perf_domain *pd, > > > + struct cpumask *pd_cpus, struct task_struct *p, int dst_cpu) > > > +{ > > > + unsigned long max_util = eenv_pd_max_util(eenv, pd_cpus, p, dst_cpu); > > > + unsigned long busy_time = eenv->pd_busy_time; > > > + > > > + if (dst_cpu >= 0) > > > + busy_time = min(eenv->pd_cap, busy_time + eenv->task_busy_time); > > > + > > > + return em_cpu_energy(pd->em_pd, max_util, busy_time, eenv->cpu_cap); > > > } > > > > > [...] > > > > @@ -6878,13 +6947,15 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) > > > if (max_spare_cap_cpu < 0 && !compute_prev_delta) > > > continue; > > > > > > + eenv_pd_busy_time(&eenv, cpus, p); > > > /* Compute the 'base' energy of the pd, without @p */ > > > - base_energy_pd = compute_energy(p, -1, cpus, pd); > > > + base_energy_pd = compute_energy(&eenv, pd, cpus, p, -1); > > > base_energy += base_energy_pd; > > > > > > /* Evaluate the energy impact of using prev_cpu. */ > > > if (compute_prev_delta) { > > > - prev_delta = compute_energy(p, prev_cpu, cpus, pd); > > > + prev_delta = compute_energy(&eenv, pd, cpus, p, > > > + prev_cpu); > > > if (prev_delta < base_energy_pd) > > > > side question: > > -base_energy_pd is the energy for the perf domain without task p > > -prev_delta is the energy for the same perf domain if task p is put on dst_cpu > > > > How can prev_delta be lower than base_energy ? > > It can happen if one of the CPU utilization is updated in the middle of feec(). Ok. A comment would be helpful > > > > > if dst_cpu doesn't belong to the perf domain, prev_delta should be > > equal to base_energy_pd > > if dst_cpu belongs to the perf domain, the compute_energy should be > > higher because the busy_time will be higher > > > > > goto unlock; > > > prev_delta -= base_energy_pd; > > > @@ -6893,8 +6964,8 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) > > > > > > /* Evaluate the energy impact of using max_spare_cap_cpu. */ > > > if (max_spare_cap_cpu >= 0) { > > > - cur_delta = compute_energy(p, max_spare_cap_cpu, cpus, > > > - pd); > > > + cur_delta = compute_energy(&eenv, pd, cpus, p, > > > + max_spare_cap_cpu); > > > if (cur_delta < base_energy_pd) > > > > same question as above > > > > > goto unlock; > > > cur_delta -= base_energy_pd; > > > -- > > > 2.36.1.124.g0e6072fb45-goog > > >