Message ID | 20221116091027.78906-1-wanghonglei@didiglobal.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp40090wru; Wed, 16 Nov 2022 01:16:58 -0800 (PST) X-Google-Smtp-Source: AA0mqf6eCcbu03PsdphCxoiVDOdAeI6cwZ4ipr1fsEHvN0kGEdRWRE9aMoxjtf+57cbvcm+vaEkJ X-Received: by 2002:a05:6402:651:b0:458:cc1b:a273 with SMTP id u17-20020a056402065100b00458cc1ba273mr18592133edx.92.1668590218217; Wed, 16 Nov 2022 01:16:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668590218; cv=none; d=google.com; s=arc-20160816; b=PyqeGUYA10vv4yqEp2VFRtcmCAe/55mGDLBn0CgN8xxow+9HtQg258pYHTZcHHAiKL 0dchY81ek5sLzE1+KZWOXeRoSnx6WB55CKCdyTYeHIQ7ON3fPD9H2u/ZQ0SA97xq4FyE romXOXZzjo4MEPGV6TPnl7TT288sqwtIpUlM9a8w5snrdcyupNm7so2csHwJSbrW6igr q4Xy4I10vmtmaQp5/Fgm/uzc3ZrspYFlJkpikxvFGypSPfsD8/ueEIkLZoCEMm44EmyZ D+1cKUaj8QDgGgXklgnk78avf7IymqQF+vlpgNq4FgWng9AtdFDgG3BlGLNZu3tkIawY 52qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=8ZXcZrMDcYONsZtSfa6EdTBBlEw55Tao6Z0rIbEB34I=; b=BLiHNASEC2rSuhuHiDgqz3Cysb5MqaFpbgGIYKZwQVpiN5zts7MgA0hRQ09lW3u9I4 At6kxkitAGQxfZ1mOuxlWuI5Si51i3NmA5VrgUHQTGfjHZBfmE5zixfUhuJndOSdLCWF A+FjGR82Q85qzT7C8Y0DcPUOBkQhpPv78kV2n2g1Wy8Dld7WvI9lg0UcgLBwJGuk4OG+ U4/FQ5jfLbx2KKMqT3S04EDrvgDmwdcaCgqvFyKdsNlHJE3pkXD3ko5KQm87ZnLnZPQk EqL8nOicTyDc8f453hWPOXJFak8WwUmeyuVe/VrTvTYzBtPUdZAuvqhzz5X7JCilk+8K mDuA== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o7-20020a056402038700b004612915d1a0si11687853edv.507.2022.11.16.01.16.34; Wed, 16 Nov 2022 01:16:58 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229766AbiKPJM5 (ORCPT <rfc822;just.gull.subs@gmail.com> + 99 others); Wed, 16 Nov 2022 04:12:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233540AbiKPJMl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 16 Nov 2022 04:12:41 -0500 X-Greylist: delayed 122 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 16 Nov 2022 01:12:39 PST Received: from mx6.didiglobal.com (mx6.didiglobal.com [111.202.70.123]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 96FE32B2 for <linux-kernel@vger.kernel.org>; Wed, 16 Nov 2022 01:12:39 -0800 (PST) Received: from mail.didiglobal.com (unknown [10.79.64.13]) by mx6.didiglobal.com (Maildata Gateway V2.8) with ESMTPS id 3DB59110243202; Wed, 16 Nov 2022 17:10:35 +0800 (CST) Received: from localhost.localdomain (10.79.64.101) by ZJY01-ACTMBX-03.didichuxing.com (10.79.64.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Wed, 16 Nov 2022 17:10:34 +0800 X-MD-Sfrom: wanghonglei@didiglobal.com X-MD-SrcIP: 10.79.64.13 From: Honglei Wang <wanghonglei@didiglobal.com> To: Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Steven Rostedt <rostedt@goodmis.org>, Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Daniel Bristot de Oliveira <bristot@redhat.com>, Valentin Schneider <vschneid@redhat.com>, <linux-kernel@vger.kernel.org> CC: Honglei Wang <wanghonglei@didiglobal.com> Subject: [PATCH] sched/core: use correct cpu_capacity in wake_affine_weight() Date: Wed, 16 Nov 2022 17:10:27 +0800 Message-ID: <20221116091027.78906-1-wanghonglei@didiglobal.com> X-Mailer: git-send-email 2.24.3 (Apple Git-128) MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.79.64.101] X-ClientProxiedBy: ZJY03-PUBMBX-01.didichuxing.com (10.79.71.12) To ZJY01-ACTMBX-03.didichuxing.com (10.79.64.13) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749643656445138287?= X-GMAIL-MSGID: =?utf-8?q?1749643656445138287?= |
Series |
sched/core: use correct cpu_capacity in wake_affine_weight()
|
|
Commit Message
Honglei Wang
Nov. 16, 2022, 9:10 a.m. UTC
It seems make more sense to do the load weight calculation with
respective cpu_capacity.
Signed-off-by: Honglei Wang <wanghonglei@didiglobal.com>
---
kernel/sched/fair.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Wed, 16 Nov 2022 at 10:12, Honglei Wang <wanghonglei@didiglobal.com> wrote: > > It seems make more sense to do the load weight calculation with > respective cpu_capacity. > > Signed-off-by: Honglei Wang <wanghonglei@didiglobal.com> > --- > kernel/sched/fair.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index e4a0b8bd941c..a9f75040969b 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -6262,13 +6262,13 @@ wake_affine_weight(struct sched_domain *sd, struct task_struct *p, > this_eff_load += task_load; > if (sched_feat(WA_BIAS)) > this_eff_load *= 100; > - this_eff_load *= capacity_of(prev_cpu); > + this_eff_load *= capacity_of(this_cpu); > > prev_eff_load = cpu_load(cpu_rq(prev_cpu)); > prev_eff_load -= task_load; > if (sched_feat(WA_BIAS)) > prev_eff_load *= 100 + (sd->imbalance_pct - 100) / 2; > - prev_eff_load *= capacity_of(this_cpu); > + prev_eff_load *= capacity_of(prev_cpu); we want to test : (cpu_load(this_rq) + task_h_load(p) ) / capacity_of(this_cpu) < cpu_load(prev_rq) / capacity_of(prev_cpu) but instead of doing expensive division, we do the below which gives the same result (cpu_load(this_rq) + task_h_load(p) ) * capacity_of(prev_cpu) < cpu_load(prev_rq) * capacity_of(this_cpu) > > /* > * If sync, adjust the weight of prev_eff_load such that if > -- > 2.14.1 >
On 2022/11/16 19:00, Vincent Guittot wrote: > On Wed, 16 Nov 2022 at 10:12, Honglei Wang <wanghonglei@didiglobal.com> wrote: >> >> It seems make more sense to do the load weight calculation with >> respective cpu_capacity. >> >> Signed-off-by: Honglei Wang <wanghonglei@didiglobal.com> >> --- >> kernel/sched/fair.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index e4a0b8bd941c..a9f75040969b 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -6262,13 +6262,13 @@ wake_affine_weight(struct sched_domain *sd, struct task_struct *p, >> this_eff_load += task_load; >> if (sched_feat(WA_BIAS)) >> this_eff_load *= 100; >> - this_eff_load *= capacity_of(prev_cpu); >> + this_eff_load *= capacity_of(this_cpu); >> >> prev_eff_load = cpu_load(cpu_rq(prev_cpu)); >> prev_eff_load -= task_load; >> if (sched_feat(WA_BIAS)) >> prev_eff_load *= 100 + (sd->imbalance_pct - 100) / 2; >> - prev_eff_load *= capacity_of(this_cpu); >> + prev_eff_load *= capacity_of(prev_cpu); > > we want to test : > (cpu_load(this_rq) + task_h_load(p) ) / capacity_of(this_cpu) < > cpu_load(prev_rq) / capacity_of(prev_cpu) > > but instead of doing expensive division, we do the below which gives > the same result > (cpu_load(this_rq) + task_h_load(p) ) * capacity_of(prev_cpu) < > cpu_load(prev_rq) * capacity_of(this_cpu) > > ha, I misunderstand the strategy, thanks for coaching, Vincent. >> >> /* >> * If sync, adjust the weight of prev_eff_load such that if >> -- >> 2.14.1 >>
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e4a0b8bd941c..a9f75040969b 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6262,13 +6262,13 @@ wake_affine_weight(struct sched_domain *sd, struct task_struct *p, this_eff_load += task_load; if (sched_feat(WA_BIAS)) this_eff_load *= 100; - this_eff_load *= capacity_of(prev_cpu); + this_eff_load *= capacity_of(this_cpu); prev_eff_load = cpu_load(cpu_rq(prev_cpu)); prev_eff_load -= task_load; if (sched_feat(WA_BIAS)) prev_eff_load *= 100 + (sd->imbalance_pct - 100) / 2; - prev_eff_load *= capacity_of(this_cpu); + prev_eff_load *= capacity_of(prev_cpu); /* * If sync, adjust the weight of prev_eff_load such that if