Message ID | 20230207045838.11243-9-ricardo.neri-calderon@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2652296wrn; Mon, 6 Feb 2023 21:01:36 -0800 (PST) X-Google-Smtp-Source: AK7set9b4oPt71HrkWIrgK/MNTfdSGr6kxmjrxZ8d09kQPNaGh1zhOpDqfhvDxxNVix5MIZZVAdH X-Received: by 2002:a62:7bd2:0:b0:593:e0d2:cda2 with SMTP id w201-20020a627bd2000000b00593e0d2cda2mr2069382pfc.4.1675746096047; Mon, 06 Feb 2023 21:01:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675746096; cv=none; d=google.com; s=arc-20160816; b=05Dp2eCTgDXXAEnwttHmjhze4wF0vvX02u6X0NA2m+UqcaYlE/NHyhgoNBjoRmcl08 pKRVtCSsNutNzqc4zLjL3n9Lrt0B+NxFBczmmyrnfBYuJqmDmUL/d4zS/f9v+rajQrxl /ImQNksa3w4lQkjafJZxsBMUBgfDkMC8P06Yu7y3+pND+TIH7O0/Fv0wspcLSrFb1E7e nZ7G3AzICPp5iu9xhSMfhk6AeNs1jF4zo07cT29j81d94nX9kNFga8yyyTwpNScAQDA4 XuP4nKTrkgXlxNQA/xLLd4J9LTL5NBqHtpP2E5a9ViyguXPKk6J5pYuvTdj7cLi5T9LJ WiMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=JqQOA/tLRvNKWcZJbfAI8eWIDo3GrqTOxSvbJyiAZOw=; b=vJew9Vptv/lXS7WRMv/ZiRBLHMsQRwbsTXe21LGG2oscvrdpo561ZVTfjegtOzTD6A blNgBseAylfzwPeiXQPNWK7V3joyq3ZcZQSDucyxqq2KwlsE/S89krP1n37lpM7CAycs zhfp9vLljzXFISALdzs+KOpzkzWZAvq8z7+OnZpwMLAq9CokSjLsuFOuSwpUcd2n1xFx 42Bf8vVCAD0WprD9mW5N3As4WL3CDqGyc4Bw2ct/woIDFSNsnKJJkJfJq5HEQ9Geoe1P 3jxnhM2yRtwsWh6h6Ugu5xyZ5gdXdICmi5Z88MDIjAidOOFOf59vxVbfWdvOnkLItHAy UXow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=i7xL4ERp; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cn15-20020a056a00340f00b0058dbb06c94dsi14135665pfb.291.2023.02.06.21.01.22; Mon, 06 Feb 2023 21:01:36 -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=i7xL4ERp; 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 S230168AbjBGEvR (ORCPT <rfc822;kmanaouilinux@gmail.com> + 99 others); Mon, 6 Feb 2023 23:51:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229647AbjBGEuu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Feb 2023 23:50:50 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B873B44BC for <linux-kernel@vger.kernel.org>; Mon, 6 Feb 2023 20:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675745449; x=1707281449; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=gCAF3pOvYu6INyXHaG52RuEfLVgO2TXZcOSdaT+lLxQ=; b=i7xL4ERpfSQxN0FM17Jn4FDvGddQB0cbWybKTC36I9Bxopqo6Djxlth1 rY/kArRBYkugTUHFt0ZgTANUhRgfFR7lMrAiIXZy2QKtyh/fQrW5tKWYO 4+mW7EZeeZyF1d0nl6dZUglbWppevqgTjl60OA21QqTHLtDgz6i0p3kiw 9gCpI93vZwLOV24ixa1tuSmMX/Nsgi6uGiG42mGPKhwSc0vkrdVRa21f1 JqTOR+T2U9uyGrkw1/R42gQtNSSLGLXo+zjtTwI4I36TxbRt3GkvRsb3g H7kVvmabjF/sZeE+Y5QLO5r+V4cAEnp263NaMZ7/uPH109n0GG2mJhLfi g==; X-IronPort-AV: E=McAfee;i="6500,9779,10613"; a="415624041" X-IronPort-AV: E=Sophos;i="5.97,278,1669104000"; d="scan'208";a="415624041" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2023 20:50:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10613"; a="668653802" X-IronPort-AV: E=Sophos;i="5.97,278,1669104000"; d="scan'208";a="668653802" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by fmsmga007.fm.intel.com with ESMTP; 06 Feb 2023 20:50:48 -0800 From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> To: "Peter Zijlstra (Intel)" <peterz@infradead.org>, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org> Cc: Ricardo Neri <ricardo.neri@intel.com>, "Ravi V. Shankar" <ravi.v.shankar@intel.com>, Ben Segall <bsegall@google.com>, Daniel Bristot de Oliveira <bristot@redhat.com>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Len Brown <len.brown@intel.com>, Mel Gorman <mgorman@suse.de>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>, Steven Rostedt <rostedt@goodmis.org>, Tim Chen <tim.c.chen@linux.intel.com>, Valentin Schneider <vschneid@redhat.com>, Ionela Voinescu <ionela.voinescu@arm.com>, x86@kernel.org, linux-kernel@vger.kernel.org, Ricardo Neri <ricardo.neri-calderon@linux.intel.com>, "Tim C . Chen" <tim.c.chen@intel.com> Subject: [PATCH v3 08/10] sched/topology: Remove SHARED_CHILD from ASYM_PACKING Date: Mon, 6 Feb 2023 20:58:36 -0800 Message-Id: <20230207045838.11243-9-ricardo.neri-calderon@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com> References: <20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com> 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,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: <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?1757147138444351078?= X-GMAIL-MSGID: =?utf-8?q?1757147138444351078?= |
Series |
sched/fair: Avoid unnecessary migrations within SMT domains
|
|
Commit Message
Ricardo Neri
Feb. 7, 2023, 4:58 a.m. UTC
Only x86 and Power7 use ASYM_PACKING. They use it differently.
Power7 has cores of equal priority, but the SMT siblings of a core have
different priorities. Parent scheduling domains do not need (nor have) the
ASYM_PACKING flag. SHARED_CHILD is not needed. Using SHARED_PARENT would
cause the topology debug code to complain.
X86 has cores of different priority, but all the SMT siblings of the core
have equal priority. It needs ASYM_PACKING at the MC level, but not at the
SMT level (it also needs it at upper levels if they have scheduling groups
of different priority). Removing ASYM_PACKING from the SMT domain causes
the topology debug code to complain.
Remove SHARED_CHILD for now. We still need a topology check that satisfies
both architectures.
Cc: Ben Segall <bsegall@google.com>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tim C. Chen <tim.c.chen@intel.com>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Valentin Schneider <vschneid@redhat.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
Changes since v2:
* Introduced this patch.
Changes since v1:
* N/A
---
include/linux/sched/sd_flags.h | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
Comments
Hi Ricardo, On Monday 06 Feb 2023 at 20:58:36 (-0800), Ricardo Neri wrote: > Only x86 and Power7 use ASYM_PACKING. They use it differently. > > Power7 has cores of equal priority, but the SMT siblings of a core have > different priorities. Parent scheduling domains do not need (nor have) the > ASYM_PACKING flag. SHARED_CHILD is not needed. Using SHARED_PARENT would > cause the topology debug code to complain. > > X86 has cores of different priority, but all the SMT siblings of the core > have equal priority. It needs ASYM_PACKING at the MC level, but not at the > SMT level (it also needs it at upper levels if they have scheduling groups > of different priority). Removing ASYM_PACKING from the SMT domain causes > the topology debug code to complain. > > Remove SHARED_CHILD for now. We still need a topology check that satisfies > both architectures. > > Cc: Ben Segall <bsegall@google.com> > Cc: Daniel Bristot de Oliveira <bristot@redhat.com> > Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> > Cc: Len Brown <len.brown@intel.com> > Cc: Mel Gorman <mgorman@suse.de> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: Tim C. Chen <tim.c.chen@intel.com> > Cc: Valentin Schneider <vschneid@redhat.com> > Cc: x86@kernel.org > Cc: linux-kernel@vger.kernel.org > Suggested-by: Valentin Schneider <vschneid@redhat.com> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> > --- > Changes since v2: > * Introduced this patch. > > Changes since v1: > * N/A > --- > include/linux/sched/sd_flags.h | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h > index 57bde66d95f7..800238854ba5 100644 > --- a/include/linux/sched/sd_flags.h > +++ b/include/linux/sched/sd_flags.h > @@ -132,12 +132,9 @@ SD_FLAG(SD_SERIALIZE, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) > /* > * Place busy tasks earlier in the domain > * > - * SHARED_CHILD: Usually set on the SMT level. Technically could be set further > - * up, but currently assumed to be set from the base domain > - * upwards (see update_top_cache_domain()). > * NEEDS_GROUPS: Load balancing flag. > */ > -SD_FLAG(SD_ASYM_PACKING, SDF_SHARED_CHILD | SDF_NEEDS_GROUPS) > +SD_FLAG(SD_ASYM_PACKING, SDF_NEEDS_GROUPS) While this silences the warning one would have gotten when removing SD_ASYM_PACKING from SMT level, it will still result in sd_asym_packing being NULL for these systems, which breaks nohz balance. That is because highest_flag_domain() still stops searching at the first level without the flag set, in this case SMT, even if levels above have the flag set. Maybe highest_flag_domain() should be changed to take into account the metadata flags? Thanks, Ionela. > > /* > * Prefer to place tasks in a sibling domain > -- > 2.25.1 > >
On Fri, Mar 03, 2023 at 11:29:52AM +0000, Ionela Voinescu wrote: > Hi Ricardo, Hi Ionela! > > On Monday 06 Feb 2023 at 20:58:36 (-0800), Ricardo Neri wrote: > > Only x86 and Power7 use ASYM_PACKING. They use it differently. > > > > Power7 has cores of equal priority, but the SMT siblings of a core have > > different priorities. Parent scheduling domains do not need (nor have) the > > ASYM_PACKING flag. SHARED_CHILD is not needed. Using SHARED_PARENT would > > cause the topology debug code to complain. > > > > X86 has cores of different priority, but all the SMT siblings of the core > > have equal priority. It needs ASYM_PACKING at the MC level, but not at the > > SMT level (it also needs it at upper levels if they have scheduling groups > > of different priority). Removing ASYM_PACKING from the SMT domain causes > > the topology debug code to complain. > > > > Remove SHARED_CHILD for now. We still need a topology check that satisfies > > both architectures. > > > > Cc: Ben Segall <bsegall@google.com> > > Cc: Daniel Bristot de Oliveira <bristot@redhat.com> > > Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> > > Cc: Len Brown <len.brown@intel.com> > > Cc: Mel Gorman <mgorman@suse.de> > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org> > > Cc: Tim C. Chen <tim.c.chen@intel.com> > > Cc: Valentin Schneider <vschneid@redhat.com> > > Cc: x86@kernel.org > > Cc: linux-kernel@vger.kernel.org > > Suggested-by: Valentin Schneider <vschneid@redhat.com> > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> > > --- > > Changes since v2: > > * Introduced this patch. > > > > Changes since v1: > > * N/A > > --- > > include/linux/sched/sd_flags.h | 5 +---- > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h > > index 57bde66d95f7..800238854ba5 100644 > > --- a/include/linux/sched/sd_flags.h > > +++ b/include/linux/sched/sd_flags.h > > @@ -132,12 +132,9 @@ SD_FLAG(SD_SERIALIZE, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) > > /* > > * Place busy tasks earlier in the domain > > * > > - * SHARED_CHILD: Usually set on the SMT level. Technically could be set further > > - * up, but currently assumed to be set from the base domain > > - * upwards (see update_top_cache_domain()). > > * NEEDS_GROUPS: Load balancing flag. > > */ > > -SD_FLAG(SD_ASYM_PACKING, SDF_SHARED_CHILD | SDF_NEEDS_GROUPS) > > +SD_FLAG(SD_ASYM_PACKING, SDF_NEEDS_GROUPS) > > While this silences the warning one would have gotten when removing > SD_ASYM_PACKING from SMT level, it will still result in sd_asym_packing > being NULL for these systems, which breaks nohz balance. That is because > highest_flag_domain() still stops searching at the first level without > the flag set, in this case SMT, even if levels above have the flag set. You are absolutely right! This how this whole discussion started. It slipped my mind. > > Maybe highest_flag_domain() should be changed to take into account the > metadata flags? What about the patch below? Search will stop if the flag has SDF_SHARED_CHILD as it does today. Otherwise it will search all the domains. --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -1773,6 +1773,12 @@ queue_balance_callback(struct rq *rq, for (__sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd); \ __sd; __sd = __sd->parent) +#define SD_FLAG(name, mflags) (name * !!((mflags) & SDF_SHARED_CHILD)) | +static const unsigned int SD_SHARED_CHILD_MASK = +#include <linux/sched/sd_flags.h> +0; +#undef SD_FLAG + /** * highest_flag_domain - Return highest sched_domain containing flag. * @cpu: The CPU whose highest level of sched domain is to @@ -1781,15 +1787,19 @@ queue_balance_callback(struct rq *rq, * for the given CPU. * * Returns the highest sched_domain of a CPU which contains the given flag. - */ +*/ static inline struct sched_domain *highest_flag_domain(int cpu, int flag) { struct sched_domain *sd, *hsd = NULL; for_each_domain(cpu, sd) { - if (!(sd->flags & flag)) + if (sd->flags & flag) { + hsd = sd; + continue; + } + + if (flag & SD_SHARED_CHILD_MASK) break; - hsd = sd; } return hsd; > > Thanks, > Ionela. > > > > > /* > > * Prefer to place tasks in a sibling domain > > -- > > 2.25.1 > > > >
Hey, On Sunday 05 Mar 2023 at 11:08:11 (-0800), Ricardo Neri wrote: > On Fri, Mar 03, 2023 at 11:29:52AM +0000, Ionela Voinescu wrote: > > Hi Ricardo, > > Hi Ionela! > > > > > On Monday 06 Feb 2023 at 20:58:36 (-0800), Ricardo Neri wrote: > > > Only x86 and Power7 use ASYM_PACKING. They use it differently. > > > > > > Power7 has cores of equal priority, but the SMT siblings of a core have > > > different priorities. Parent scheduling domains do not need (nor have) the > > > ASYM_PACKING flag. SHARED_CHILD is not needed. Using SHARED_PARENT would > > > cause the topology debug code to complain. > > > > > > X86 has cores of different priority, but all the SMT siblings of the core > > > have equal priority. It needs ASYM_PACKING at the MC level, but not at the > > > SMT level (it also needs it at upper levels if they have scheduling groups > > > of different priority). Removing ASYM_PACKING from the SMT domain causes > > > the topology debug code to complain. > > > > > > Remove SHARED_CHILD for now. We still need a topology check that satisfies > > > both architectures. > > > > > > Cc: Ben Segall <bsegall@google.com> > > > Cc: Daniel Bristot de Oliveira <bristot@redhat.com> > > > Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> > > > Cc: Len Brown <len.brown@intel.com> > > > Cc: Mel Gorman <mgorman@suse.de> > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org> > > > Cc: Tim C. Chen <tim.c.chen@intel.com> > > > Cc: Valentin Schneider <vschneid@redhat.com> > > > Cc: x86@kernel.org > > > Cc: linux-kernel@vger.kernel.org > > > Suggested-by: Valentin Schneider <vschneid@redhat.com> > > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> > > > --- > > > Changes since v2: > > > * Introduced this patch. > > > > > > Changes since v1: > > > * N/A > > > --- > > > include/linux/sched/sd_flags.h | 5 +---- > > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > > > diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h > > > index 57bde66d95f7..800238854ba5 100644 > > > --- a/include/linux/sched/sd_flags.h > > > +++ b/include/linux/sched/sd_flags.h > > > @@ -132,12 +132,9 @@ SD_FLAG(SD_SERIALIZE, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) > > > /* > > > * Place busy tasks earlier in the domain > > > * > > > - * SHARED_CHILD: Usually set on the SMT level. Technically could be set further > > > - * up, but currently assumed to be set from the base domain > > > - * upwards (see update_top_cache_domain()). > > > * NEEDS_GROUPS: Load balancing flag. > > > */ > > > -SD_FLAG(SD_ASYM_PACKING, SDF_SHARED_CHILD | SDF_NEEDS_GROUPS) > > > +SD_FLAG(SD_ASYM_PACKING, SDF_NEEDS_GROUPS) > > > > While this silences the warning one would have gotten when removing > > SD_ASYM_PACKING from SMT level, it will still result in sd_asym_packing > > being NULL for these systems, which breaks nohz balance. That is because > > highest_flag_domain() still stops searching at the first level without > > the flag set, in this case SMT, even if levels above have the flag set. > > You are absolutely right! This how this whole discussion started. It > slipped my mind. > > > > > Maybe highest_flag_domain() should be changed to take into account the > > metadata flags? > > What about the patch below? Search will stop if the flag has > SDF_SHARED_CHILD as it does today. Otherwise it will search all the > domains. > > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -1773,6 +1773,12 @@ queue_balance_callback(struct rq *rq, > for (__sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd); \ > __sd; __sd = __sd->parent) > > +#define SD_FLAG(name, mflags) (name * !!((mflags) & SDF_SHARED_CHILD)) | > +static const unsigned int SD_SHARED_CHILD_MASK = > +#include <linux/sched/sd_flags.h> > +0; > +#undef SD_FLAG > + > /** > * highest_flag_domain - Return highest sched_domain containing flag. > * @cpu: The CPU whose highest level of sched domain is to > @@ -1781,15 +1787,19 @@ queue_balance_callback(struct rq *rq, > * for the given CPU. > * > * Returns the highest sched_domain of a CPU which contains the given flag. > - */ > +*/ ^^^ likely an unintended change > static inline struct sched_domain *highest_flag_domain(int cpu, int flag) > { > struct sched_domain *sd, *hsd = NULL; > > for_each_domain(cpu, sd) { > - if (!(sd->flags & flag)) > + if (sd->flags & flag) { > + hsd = sd; > + continue; > + } > + There might be room for a comment here: /* * If the flag is not set and is known to be shared with lower * domains, stop the search, as it won't be found further up. */ > + if (flag & SD_SHARED_CHILD_MASK) > break; > - hsd = sd; > } > > return hsd; It looks nice and sane to me - I've not compiled or tested it :). Thanks, Ionela. > > > > > Thanks, > > Ionela. > > > > > > > > /* > > > * Prefer to place tasks in a sibling domain > > > -- > > > 2.25.1 > > > > > >
On Mon, Mar 06, 2023 at 01:10:37PM +0000, Ionela Voinescu wrote: > Hey, > > On Sunday 05 Mar 2023 at 11:08:11 (-0800), Ricardo Neri wrote: > > On Fri, Mar 03, 2023 at 11:29:52AM +0000, Ionela Voinescu wrote: > > > Hi Ricardo, > > > > Hi Ionela! > > > > > > > > On Monday 06 Feb 2023 at 20:58:36 (-0800), Ricardo Neri wrote: > > > > Only x86 and Power7 use ASYM_PACKING. They use it differently. > > > > > > > > Power7 has cores of equal priority, but the SMT siblings of a core have > > > > different priorities. Parent scheduling domains do not need (nor have) the > > > > ASYM_PACKING flag. SHARED_CHILD is not needed. Using SHARED_PARENT would > > > > cause the topology debug code to complain. > > > > > > > > X86 has cores of different priority, but all the SMT siblings of the core > > > > have equal priority. It needs ASYM_PACKING at the MC level, but not at the > > > > SMT level (it also needs it at upper levels if they have scheduling groups > > > > of different priority). Removing ASYM_PACKING from the SMT domain causes > > > > the topology debug code to complain. > > > > > > > > Remove SHARED_CHILD for now. We still need a topology check that satisfies > > > > both architectures. > > > > > > > > Cc: Ben Segall <bsegall@google.com> > > > > Cc: Daniel Bristot de Oliveira <bristot@redhat.com> > > > > Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> > > > > Cc: Len Brown <len.brown@intel.com> > > > > Cc: Mel Gorman <mgorman@suse.de> > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org> > > > > Cc: Tim C. Chen <tim.c.chen@intel.com> > > > > Cc: Valentin Schneider <vschneid@redhat.com> > > > > Cc: x86@kernel.org > > > > Cc: linux-kernel@vger.kernel.org > > > > Suggested-by: Valentin Schneider <vschneid@redhat.com> > > > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> > > > > --- > > > > Changes since v2: > > > > * Introduced this patch. > > > > > > > > Changes since v1: > > > > * N/A > > > > --- > > > > include/linux/sched/sd_flags.h | 5 +---- > > > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > > > > > diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h > > > > index 57bde66d95f7..800238854ba5 100644 > > > > --- a/include/linux/sched/sd_flags.h > > > > +++ b/include/linux/sched/sd_flags.h > > > > @@ -132,12 +132,9 @@ SD_FLAG(SD_SERIALIZE, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) > > > > /* > > > > * Place busy tasks earlier in the domain > > > > * > > > > - * SHARED_CHILD: Usually set on the SMT level. Technically could be set further > > > > - * up, but currently assumed to be set from the base domain > > > > - * upwards (see update_top_cache_domain()). > > > > * NEEDS_GROUPS: Load balancing flag. > > > > */ > > > > -SD_FLAG(SD_ASYM_PACKING, SDF_SHARED_CHILD | SDF_NEEDS_GROUPS) > > > > +SD_FLAG(SD_ASYM_PACKING, SDF_NEEDS_GROUPS) > > > > > > While this silences the warning one would have gotten when removing > > > SD_ASYM_PACKING from SMT level, it will still result in sd_asym_packing > > > being NULL for these systems, which breaks nohz balance. That is because > > > highest_flag_domain() still stops searching at the first level without > > > the flag set, in this case SMT, even if levels above have the flag set. > > > > You are absolutely right! This how this whole discussion started. It > > slipped my mind. > > > > > > > > Maybe highest_flag_domain() should be changed to take into account the > > > metadata flags? > > > > What about the patch below? Search will stop if the flag has > > SDF_SHARED_CHILD as it does today. Otherwise it will search all the > > domains. > > > > --- a/kernel/sched/sched.h > > +++ b/kernel/sched/sched.h > > @@ -1773,6 +1773,12 @@ queue_balance_callback(struct rq *rq, > > for (__sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd); \ > > __sd; __sd = __sd->parent) > > > > +#define SD_FLAG(name, mflags) (name * !!((mflags) & SDF_SHARED_CHILD)) | > > +static const unsigned int SD_SHARED_CHILD_MASK = > > +#include <linux/sched/sd_flags.h> > > +0; > > +#undef SD_FLAG > > + > > /** > > * highest_flag_domain - Return highest sched_domain containing flag. > > * @cpu: The CPU whose highest level of sched domain is to > > @@ -1781,15 +1787,19 @@ queue_balance_callback(struct rq *rq, > > * for the given CPU. > > * > > * Returns the highest sched_domain of a CPU which contains the given flag. > > - */ > > +*/ > ^^^ > likely an unintended change Yes! I will remove it in the patch I post. > > static inline struct sched_domain *highest_flag_domain(int cpu, int flag) > > { > > struct sched_domain *sd, *hsd = NULL; > > > > for_each_domain(cpu, sd) { > > - if (!(sd->flags & flag)) > > + if (sd->flags & flag) { > > + hsd = sd; > > + continue; > > + } > > + > > There might be room for a comment here: > /* > * If the flag is not set and is known to be shared with lower > * domains, stop the search, as it won't be found further up. > */ Sure, I can and a comment to this effect. > > + if (flag & SD_SHARED_CHILD_MASK) > > break; > > - hsd = sd; > > } > > > > return hsd; > > It looks nice and sane to me - I've not compiled or tested it :). Thank you very much for your feedback! BR, Ricardo
diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h index 57bde66d95f7..800238854ba5 100644 --- a/include/linux/sched/sd_flags.h +++ b/include/linux/sched/sd_flags.h @@ -132,12 +132,9 @@ SD_FLAG(SD_SERIALIZE, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) /* * Place busy tasks earlier in the domain * - * SHARED_CHILD: Usually set on the SMT level. Technically could be set further - * up, but currently assumed to be set from the base domain - * upwards (see update_top_cache_domain()). * NEEDS_GROUPS: Load balancing flag. */ -SD_FLAG(SD_ASYM_PACKING, SDF_SHARED_CHILD | SDF_NEEDS_GROUPS) +SD_FLAG(SD_ASYM_PACKING, SDF_NEEDS_GROUPS) /* * Prefer to place tasks in a sibling domain