Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7109106rwb; Mon, 12 Dec 2022 10:08:27 -0800 (PST) X-Google-Smtp-Source: AA0mqf6OcguEaapRKt1PLJYRP0EDSEeapnCnGyTKkLFAhkAxHSn8gU3G3wNHneFKGtGhv6p6q2Hi X-Received: by 2002:aa7:8b42:0:b0:566:900e:1d8c with SMTP id i2-20020aa78b42000000b00566900e1d8cmr17945512pfd.8.1670868507517; Mon, 12 Dec 2022 10:08:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670868507; cv=none; d=google.com; s=arc-20160816; b=KGcicX5EaG21ZsCXF80D2aV3v4t20h4nCm1o+VflRHJ3hiDNTqEWrrGU06yA+bRCjB 5XwiZX5mbipC0fnc4jwClH22Pc0lqECGcZJn0TQiUh2WDhuHZh/fvOXNNdJD4s53+EGz 8KGRRzmampDhHzr3fam6JKwM4UKhkyCCelGDIkFO5RHDZQVW0zb7tZUcKZA6lsSWoRd1 tjCH+e+zJNrvh8lYTEFqR486xRnH2PkST4TqxvCEVviQDVJX9L+hZC4Tad1Y63T4yun1 ll0K0L1+IVm1veLkC84ShdVfQO/NJNj/nCiOnDZ5aiJ5yFp+4L1WA/oXjWv6e9Heh7uL IUWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=W3TEJsc27r/lLcNPUeAkvoS9G8zhQbojuc6ZwnBFVqc=; b=NWNILmhR4CzcT47xrqsARF/HwiM+z+FMk/5VY8/MRP1dhbKFUufcz4L48qqOPkUdML 1NZDlWo4/7YyC2tlEyQrULI7u4wxQtLlALRYVel7nfIz2rGBVgb3JIiQZBV6XHijqi8V mfdnddQJc0sUvfzx9lCt8TOOSR+aRaYYEYmLMwWdIMje4TGGbc4kwUWKK7FOM5BqEtK3 hkQMFYruOJ1wq1EJMlboHLqec1J9SSJlsKhl3zRtt9DoG4DJownZInQje3+GJQ/FMGwT F+cFvKiZlBLG7Y4FaAn3UFw7SKpldvhtNM4HvYTB5OJr+Wx4E9Kj0G61O2IvjmWrFa26 sGng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="EMN7Nqe/"; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ay13-20020a056a00300d00b0056b82fbafebsi10020423pfb.379.2022.12.12.10.08.17; Mon, 12 Dec 2022 10:08:27 -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; dkim=pass header.i=@intel.com header.s=Intel header.b="EMN7Nqe/"; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232081AbiLLRqb (ORCPT + 74 others); Mon, 12 Dec 2022 12:46:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229600AbiLLRq3 (ORCPT ); Mon, 12 Dec 2022 12:46:29 -0500 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5312E13E8B for ; Mon, 12 Dec 2022 09:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670867188; x=1702403188; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=afIynkK3XdPDB68PgKvZAMCEcWEAEYRGQhKxXaE9LO4=; b=EMN7Nqe/JolV1HsB/qFt+K/XQ04H579hiOpxurAlTQ3fwgCcrinKidrA RpWUNd5NyxTcyWulnSa5NWOKCsoWx3MHpusAGi4voirAcbcVstKv20C1e 0XXtFe7j9uUiiEwL8cuZI34eCDjuhJn1fUj7mNfncMHiaEA8WnRWAsmgT fmT2sHPeIvXr/eC0Ody12vdJ4px8OkhsU9mFwGIqzTwH6zMOnepTcqERQ kDXgyWwa9lWS2sy94+4rPxgJvc6eENoYBkyoxHJiZcvpxoCr5OFil88Gh 46ubUd/5oHjYqcO12NCU1nezSyZ3p+Z2hOO8HowyCTQ4G/2zjhjNR3byt A==; X-IronPort-AV: E=McAfee;i="6500,9779,10559"; a="305559526" X-IronPort-AV: E=Sophos;i="5.96,239,1665471600"; d="scan'208";a="305559526" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2022 09:46:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10559"; a="650417773" X-IronPort-AV: E=Sophos;i="5.96,239,1665471600"; d="scan'208";a="650417773" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by fmsmga007.fm.intel.com with ESMTP; 12 Dec 2022 09:46:26 -0800 Date: Mon, 12 Dec 2022 09:54:33 -0800 From: Ricardo Neri To: Dietmar Eggemann Cc: "Peter Zijlstra (Intel)" , Juri Lelli , Vincent Guittot , Ricardo Neri , "Ravi V. Shankar" , Ben Segall , Daniel Bristot de Oliveira , Len Brown , Mel Gorman , "Rafael J. Wysocki" , Srinivas Pandruvada , Steven Rostedt , Tim Chen , Valentin Schneider , x86@kernel.org, linux-kernel@vger.kernel.org, "Tim C . Chen" Subject: Re: [PATCH v2 3/7] sched: Teach arch_asym_cpu_priority() the idle state of SMT siblings Message-ID: <20221212175433.GB27353@ranerica-svr.sc.intel.com> References: <20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com> <20221122203532.15013-4-ricardo.neri-calderon@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE 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 Tue, Dec 06, 2022 at 06:54:39PM +0100, Dietmar Eggemann wrote: > On 22/11/2022 21:35, Ricardo Neri wrote: > > Some processors (e.g., Intel processors with ITMT) use asym_packing to > > balance load between physical cores with SMT. In such case, a core with all > > its SMT siblings idle is more desirable than another with one or more busy > > siblings. > > > > Other processors (e.g, Power7 with SMT8) use asym_packing to balance load > > among SMT siblings of different priority, regardless of their idle state. > > > > Add a new parameter, check_smt, that architectures can use as needed. > > [...] > > > Changes since v1: > > * Introduced this patch. > > [...] > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index d18947a9c03e..0e4251f83807 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -142,8 +142,11 @@ __setup("sched_thermal_decay_shift=", setup_sched_thermal_decay_shift); > > #ifdef CONFIG_SMP > > /* > > * For asym packing, by default the lower numbered CPU has higher priority. > > + * > > + * When doing ASYM_PACKING at the "MC" or higher domains, architectures may > > There is this new CLUSTER level between SMT and MC. This is a good catch! I will update the comment to say "domains above SMT". > > > + * want to check the idle state of the SMT siblngs of @cpu. > > s/siblngs/siblings > > The scheduler calls sched_asym_prefer(..., true) from > find_busiest_queue(), asym_active_balance() and nohz_balancer_kick() In these places we are comparing two specific CPUs, of which the idle state of its siblings impact their throughput and, in consequence, the decision of attempt to balance load. In the places were sched_asym_prefer(...., false) is called we compare the destination CPU with a CPU that bears the priority of a sched group, regardless of the idle state of its siblings. > even from SMT layer on !x86. This is true, but the default arch_asym_cpu_priority ignores check_smt. > So I guess a `bool check_smt` wouldn't be > sufficient to distinguish whether sched_smt_siblings_idle() should be > called or not. But it is the caller who determines whether the idle state of the SMT siblings of @cpu may be relevant. > To me this comment is a little bit misleading. Not an > issue currently since there is only the x86 overwrite right now. If my justification make sense to you, I can expand the comment to state that the caller decides whether check_smt is needed but arch-specific implementations are free to ignore it. Thanks and BR, Ricardo