Received: by 2002:a05:6520:1682:b0:147:d1a0:b502 with SMTP id ck2csp5597669lkb; Mon, 11 Oct 2021 09:40:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzB8J5TmBfhDju7bxnDDmXOM7mYWpEgjhqt+DDfmtfSWVzjKuHcgNbbWGMC4JeM6sIOwr8w X-Received: by 2002:a17:90a:5d01:: with SMTP id s1mr60426pji.16.1633970415199; Mon, 11 Oct 2021 09:40:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633970415; cv=none; d=google.com; s=arc-20160816; b=wRZwnqDrPOPOcJIqIj/h0mF+Q58vhjExDrV8oeAhGxhQCwxNjXY6MSWuxO63d1E3dg si0x9/OFAEn109KQQIcghYuWxLzXSB5HqmTO8Rehh28FRRti6udkY0RU2SujQSO6MKUk MGc2Co2vDmaXY4Ac7NGT7q32M2go25VGHvWOwETV02AeixxP4DQ4a1YjwGYfcth4yEg1 W8K5VQ9/Vv5ZO5cd+G8L2r93HBT39mcyg62T4L9awT66dfq4ry2abE2UipM+mz47Ue28 88USzq+G/1pghSD6iEAjhWWSU9YsUvuGhBVS4oBl5fRlxrsggHISzi6YWrWgRFGI9pVR gr0Q== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=rToZIEvmSd0sXDqBtngTdqWD8dGU3xnhPotlR/COE4Y=; b=vj7p6YnEiF8/gmYBManoUMvCl+1nI62Xo+hZhjRYGgKJxZf0fTtDjP9XnIUXHkd1Da JA+GuGVqq6ryof4wssvRPvYP50t8bJBDgy7bZMH8DyAYKQ4NapvLjziJitBfbBPKsDpX HoXHZE57Pk/p8MwVpNXzPMVE5F3CmPPqQi/2F9D1iO0Kg1DfSMWgXvBJVNGr6fwhLvc9 ThtbJcWL6wNEqfGOxI0vHHRKgbTkvoxrHZerDmXmKDSYCmBt6nU08C4KRfvLLan48Dgq ZtiEjfwzobHgZ2olpTQwdwzIDoYePTt2ULzbRvPWumo1s26+wszSdfloEZi2yduTIVe6 ULmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 68si10072089pfe.367.2021.10.11.09.40.02; Mon, 11 Oct 2021 09:40:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235523AbhJKPAG (ORCPT + 99 others); Mon, 11 Oct 2021 11:00:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:41324 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234614AbhJKPAF (ORCPT ); Mon, 11 Oct 2021 11:00:05 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6945D60EBD; Mon, 11 Oct 2021 14:58:04 +0000 (UTC) Date: Mon, 11 Oct 2021 10:58:02 -0400 From: Steven Rostedt To: Tao Zhou Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira Subject: Re: [PATCH] sched/fair: Use this_sd->weight to calculate span_avg Message-ID: <20211011105802.344b907c@gandalf.local.home> In-Reply-To: <20211009181055.20512-1-tao.zhou@linux.dev> References: <20211009181055.20512-1-tao.zhou@linux.dev> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 10 Oct 2021 02:10:55 +0800 Tao Zhou wrote: > avg_idle, avg_cost got from this_rq and this_sd. I think > use this_sd->weight to calculate and estimate the number > of loop cpus in the target domain. If that's the case, then shouldn't the CPUs to be checked come from this_sd as well? I mean, at the beginning of the function we have: this_sd = rcu_dereference(*this_cpu_ptr(&sd_llc)); if (!this_sd) return -1; cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr); Where "cpus" comes from sd, and not this_sd. > --- > kernel/sched/fair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index f6a05d9b5443..7fab7b70814c 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -6300,7 +6300,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool > avg_idle = this_rq->wake_avg_idle; > avg_cost = this_sd->avg_scan_cost + 1; > > - span_avg = sd->span_weight * avg_idle; > + span_avg = this_sd->span_weight * avg_idle; > if (span_avg > 4*avg_cost) > nr = div_u64(span_avg, avg_cost); > else And after this code, the nr that is determined from the above, is for limiting the looping over those CPUs from sd, not this_sd: for_each_cpu_wrap(cpu, cpus, target + 1) { if (has_idle_core) { i = select_idle_core(p, cpu, cpus, &idle_cpu); if ((unsigned int)i < nr_cpumask_bits) return i; } else { if (!--nr) return -1; idle_cpu = __select_idle_cpu(cpu, p); if ((unsigned int)idle_cpu < nr_cpumask_bits) break; } } I'm guessing there's nothing wrong here. But, I don't fully understand it myself. -- Steve