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;
Date:   Sat, 8 Jul 2023 21:17:10 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Peter Zijlstra <peterz@infradead.org>
CC:     K Prateek Nayak <kprateek.nayak@amd.com>,
        <linux-kernel@vger.kernel.org>,
        <linux-tip-commits@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
        <x86@kernel.org>, Gautham Shenoy <gautham.shenoy@amd.com>
Subject: Re: [tip: sched/core] sched/fair: Multi-LLC select_idle_sibling()
Message-ID: <ZKlh1u2kkHzHY/nB@chenyu5-mobl2>
References: <20230601111326.GV4253@hirez.programming.kicks-ass.net>
 <20230601115643.GX4253@hirez.programming.kicks-ass.net>
 <20230601120001.GJ38236@hirez.programming.kicks-ass.net>
 <20230601144706.GA559454@hirez.programming.kicks-ass.net>
 <7bee9860-2d2a-067b-adea-04012516095c@amd.com>
 <20230602065438.GB620383@hirez.programming.kicks-ass.net>
 <bd083d8d-023a-698e-701b-725f1b15766e@amd.com>
 <20230613082536.GI83892@hirez.programming.kicks-ass.net>
 <f212f491-cd3f-6eee-20d7-8f9ab8937902@amd.com>
 <20230705115702.GY4253@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230705115702.GY4253@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?dGRerr3griMhIjx0Anhn0Q7ehUvKACZpYUTx7PJ/OjXH9w2RMVwT20lOgSvR?=
 =?us-ascii?Q?d3R7NevEjDDtaEPJWwZ3KWqJjrMdsp457AqUPnaPFTEM7PqnSitcgfkgTXMV?=
 =?us-ascii?Q?wo/GRF816CGjiuqmuzpMTcVkOTYbykMUBHstbXFLN3DiLxKs2FJ7OfGOi7GB?=
 =?us-ascii?Q?fObpo2vjvxTagxOcRP1B8OF6tWSRJKnpUQA2WtV70Op5NQyZAf/jWkKD7boP?=
 =?us-ascii?Q?pWLF2zTNYbL7LC0bzx+1IP+YP+h+iZsTUWVe9jwXbkbA7o3O2VMG6J7LoaEd?=
 =?us-ascii?Q?Ch4jgPZ1DbnU/DpINXOxwkQpgzt+lOtXT0I3nGvksqVWUKwrN6g0JBwiZyvj?=
 =?us-ascii?Q?N3El6VqJMUX0JbVfC90uEPQRVmtd3j78XzJuhZvwbGWTCVYC9X5v7jAqnt8g?=
 =?us-ascii?Q?y/3Z6FnXuw7Jh8SRNizeIKOBNtUkYm1mV8Zz5L/NeJGpOiF9Yd/8THHjbcKw?=
 =?us-ascii?Q?QIs9KUkvRt0WNHZuYnH3aFHjL9vTpvODW1DZNFphLds0U/5fkTteemqOApid?=
 =?us-ascii?Q?jk0bvMheN0Xf+955+0rOxm6D+UXmaQqMFDhISmIgBCnC2Rhw4pQImlxEQmTJ?=
 =?us-ascii?Q?4rY0MvJGsUetGwx1w+7KxvluqgDSaB6NwQqvbARhpqS53NgBv1kIVMYNORdA?=
 =?us-ascii?Q?DTLWiK8vYjorhtLZvx/ri5EWEX+m0XGkQ2Fo+epv6U9z633ztmky0ZZasAzy?=
 =?us-ascii?Q?KCrLAGmfC7wxewzXBH/5zVZePlHd14z533fsrNhBzCVJ/N5oAzWbhdNf2Svs?=
 =?us-ascii?Q?OQghtY/iEjNSVaMFRrImPpuwRWko24TFPWgFIuEgDRAMe4QwTkTZrsvh5PyP?=
 =?us-ascii?Q?1M3XsDE9SF+0FgB7eoybEPN09fCU023MxF4l49baD8xKcYyXxGsvhUdMJ92n?=
 =?us-ascii?Q?Oq8zfGwP0SnU/Mp9xLJXC2wxINE98Jsnlk2jvt3e/smD+crIbF6hIG1lsy11?=
 =?us-ascii?Q?nsiNtN4hB5CEJgFXVPBAYeonv1PtGvFJC126O5PPB+D+klzuikuF2e0/S6D4?=
 =?us-ascii?Q?8pEswR/IoB76WckjNfL9c5ua8nQCZSnl8wPfwB89GHI9iCXh2brZCMP8YhrA?=
 =?us-ascii?Q?LiKJDYyiFUH2BdVMIdH5abCF+6XzsycyWnJnFMnuJwnw10YwHdT5m/PAbz4Y?=
 =?us-ascii?Q?9CVJaz5undCfLiJcqGg/Bba6prLRvR5sQdPcXxQVz1ab4Ub+QslzFE8gfoYU?=
 =?us-ascii?Q?jRj5x5Pq13NbUTdoRu58Rpg00b255Zl6Uh2/uhjK46UMg3+9df2gplZglnP/?=
 =?us-ascii?Q?CogVv6HE5Qhi5tlyFY59tLO2PNr8EfUtw0jGYu7gLmPqXmelOZjOZFUaTO5C?=
 =?us-ascii?Q?b7QKp0EIvkT1gFzwy+S6lSl30lexH0jqyLAGSVOzf5dwACJFvUTW825dwdb3?=
 =?us-ascii?Q?36qOg9kuy3cFQS77Gr+8s9Y6y4QymdqsajJZkhKRgP7HNBQ0xS2Ioc7/5H65?=
 =?us-ascii?Q?D3Ujra+nPZf7V7sW3ea8g/oku7tR8rrXCo3K6YjAfKA8/eXnnzZWs+9s7pGn?=
 =?us-ascii?Q?GpGoSOXLIkZ9Mk/G3OFcAu1Rf4cwnwaoofIEsSCeZ+TPg5a0/PN51FLN4bj5?=
 =?us-ascii?Q?8wCwYvjVKqVIhAEzKtO9zUKLuli7b3Invs2+38pv?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 71c6d526-485a-430e-1701-08db7fb5abad
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2023 13:17:25.2559
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 4vqfQgHx1xcTykGexYISUgNUEb8x12F0x6mTSJ7dhijE6u/pzqx0ANNINttLSRSLqmkxIYK89MVxiMXuGaEhUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4814
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED
        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

On 2023-07-05 at 13:57:02 +0200, Peter Zijlstra wrote:
> On Fri, Jun 16, 2023 at 12:04:48PM +0530, K Prateek Nayak wrote:
> 
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -596,7 +596,7 @@ static inline int x86_sched_itmt_flags(v
>  #ifdef CONFIG_SCHED_MC
>  static int x86_core_flags(void)
>  {
> -	return cpu_core_flags() | x86_sched_itmt_flags();
> +	return cpu_core_flags() | x86_sched_itmt_flags() | SD_IDLE_SIBLING;
>  }
I guess this flag might need to be added into the valid mask:

diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index d3a3b2646ec4..4a563e9f7b10 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1540,6 +1540,7 @@ static struct cpumask		***sched_domains_numa_masks;
 #define TOPOLOGY_SD_FLAGS		\
 	(SD_SHARE_CPUCAPACITY	|	\
 	 SD_SHARE_PKG_RESOURCES |	\
+	 SD_IDLE_SIBLING	|	\
 	 SD_NUMA		|	\
 	 SD_ASYM_PACKING)
>  #endif
>  #ifdef CONFIG_SCHED_SMT
> --- a/include/linux/sched/sd_flags.h
> +++ b/include/linux/sched/sd_flags.h
> @@ -161,3 +161,10 @@ SD_FLAG(SD_OVERLAP, SDF_SHARED_PARENT |
>   * NEEDS_GROUPS: No point in preserving domain if it has a single group.
>   */
>  SD_FLAG(SD_NUMA, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS)
> +
> +/*
> + * Search for idle CPUs in sibling groups
> + *
> + * NEEDS_GROUPS: Load balancing flag.
> + */
> +SD_FLAG(SD_IDLE_SIBLING, SDF_NEEDS_GROUPS)
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7046,6 +7046,38 @@ static int select_idle_cpu(struct task_s
>  }
>  
>  /*
> + * For the multiple-LLC per node case, make sure to try the other LLC's if the
> + * local LLC comes up empty.
> + */
> +static int
> +select_idle_node(struct task_struct *p, struct sched_domain *sd, int target)
> +{
> +	struct sched_domain *parent = sd->parent;
> +	struct sched_group *sg;
> +
> +	/* Make sure to not cross nodes. */
> +	if (!parent || parent->flags & SD_NUMA)
> +		return -1;
> +
> +	sg = parent->groups;
> +	do {
> +		int cpu = cpumask_first(sched_group_span(sg));
> +		struct sched_domain *sd_child = per_cpu(sd_llc, cpu);
>
I wonder if we can use rcu_dereference() in case the cpu hotplug
changes the content sd_llc points to. (I'm still thinking of the
symptom you described here:)
https://lore.kernel.org/lkml/20230605190746.GX83892@hirez.programming.kicks-ass.net/

I'll launch some tests with this version on Sapphire Rapids(and with/without LLC-split hack patch).

thanks,
Chenyu