From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazon11010060.outbound.protection.outlook.com [52.101.193.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA6A1388364 for ; Mon, 20 Apr 2026 08:36:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.193.60 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776674198; cv=fail; b=P1ViPJJTDepQC5b3yjKppGxVzrvHAJhdDNsQFsd3yb3k0pO/8jE+Ev/1B5Q+z5QW0mN99SzSGzjgb7rpPcsses+4wlo/kGeB3cJcAmU5oPCA+ZDtUzBR2lkZNZsK/CjhmDabdBGRi3eW2GqARL14VHHZ9b1i1wVI3MJw28N3EeQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776674198; c=relaxed/simple; bh=V057hhuYkYZL4ss4ClR23ThYUbTQpCV1HNk0hAiSypM=; h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type: Content-Disposition:In-Reply-To:MIME-Version; b=J26RxR0PHyWip1GQwbUmQziifVmXhY5N6DeNxz9pcnyB4JhnJVCOuyQn+Cv9goY+ltXw6v5i9m2VacHXPk5qvJk+8nuVtEte1ix5eEoP2hRWdfOM6pz7XyD4JwI8kaSi1vssAftRiCgqhpDiBC+DAmh8cSIf0/6rDNa//ciCCMM= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com; spf=fail smtp.mailfrom=nvidia.com; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b=BkbTzwwb; arc=fail smtp.client-ip=52.101.193.60 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nvidia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="BkbTzwwb" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=auNDPY0Z2DT44ozGzWkDoIZudmlwE4PlvMuS4Qc6DzaWNQ7eqRp8Gl4T6w7G30Tk57mYg1qOTy4yWaJ7LDy8mIkTZer/C4m9Q2C8y978vDphb3phA2lfW4Yrx4lB48xwlBu9cFL0Pxu5BnAE9CYf/iZkzUv1rTv9Mh5OevfBgE+ghQPkcsRx8exFKp/wrS0lWVFtKREMTZQnUWOaGmZDQ0ez9d09oeDW6H1DMQ48Y1Fzd4tn+w/7UycGeDtyFlWpKcsL3Y+X225nYY2ZP7Hqp3tmLhgeS/HYTIvr/7p3lqs/uohv0wlA7o4D+aSStZQNSeyGxHCVVCgi2kVS+11Qrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MD/astLYD4O1QhzZ1KaBUiVtpKUxLnisKSMUuwLrd6o=; b=tCbe7jh07TmHQxuqnyEsEGAOGi/nABnfzTh3cctFwGaBUeG7w3kkI9Itw2CCc8RGHHKJOHpDwWdGADzczLDSJ0hD8nKJeiIqimKcqbsMlYCZe+xV7Iic8/QYo7qxD6CNPrGLzyS5Jby85qe0PWnX5eGc6TcDBwpTHNC4cMtnrEroqQs72ZL/rxVRT3NIn7pDqQKRGhIId19LjkYdOgCbGuyy4x8jcXvAAKiVRUCua1Pc6RMmsxzDbaML7jcxoz+LWPHyC4ehKNxsg6Kua0vSteMr2KWH+zNssDDq13HgGz7J1eg31BlscX3gYVui6U8Fmg1Dxhxj/glkGQeTVre8aQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MD/astLYD4O1QhzZ1KaBUiVtpKUxLnisKSMUuwLrd6o=; b=BkbTzwwbHh+WiYU9AMsvGRrlxtX5GMNfIm0PFZM8Skd9qy0vsgPex5aME6ikNMzwztiqa6UisjMcOVVqrM1KFG5KU63ixBF8ng0aldhZGG2y2OfvS/dY9mRih+MQLD5/SOiQyyqZ0LJLVCMpMpHTqQFbQGoWI1m8Ftr0FE04c4vyXbJrGn64KxdfUuauLz9/vI9ueSWAexjQwg3/zmgAD31uYSYiMAdWWJSX/7O6zJfoc2z8S/PgdAlBeM/g1zuKhpLqpma0SkzKzpYVxFKQP4gWHnrJXSYTRBs34UZV9jTELpsU7PCLQ4RmMaa5VIcph4YmAGDMfqdOiDEkIhQjVA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from LV8PR12MB9620.namprd12.prod.outlook.com (2603:10b6:408:2a1::19) by MN0PR12MB5714.namprd12.prod.outlook.com (2603:10b6:208:371::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.15; Mon, 20 Apr 2026 08:36:31 +0000 Received: from LV8PR12MB9620.namprd12.prod.outlook.com ([fe80::299d:f5e0:3550:1528]) by LV8PR12MB9620.namprd12.prod.outlook.com ([fe80::299d:f5e0:3550:1528%5]) with mapi id 15.20.9846.014; Mon, 20 Apr 2026 08:36:31 +0000 Date: Mon, 20 Apr 2026 10:36:22 +0200 From: Andrea Righi To: K Prateek Nayak Cc: Dietmar Eggemann , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Christian Loehle , Koba Ko , Felix Abecassis , Balbir Singh , Shrikanth Hegde , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection Message-ID: References: <20260403053654.1559142-1-arighi@nvidia.com> <20260403053654.1559142-2-arighi@nvidia.com> <64fe32e0-d428-42bb-beb4-2656d8781b0f@arm.com> <7313ba07-7b87-447c-9c48-2f6b2b53ac94@amd.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7313ba07-7b87-447c-9c48-2f6b2b53ac94@amd.com> X-ClientProxiedBy: MI1PEPF000008CF.ITAP293.PROD.OUTLOOK.COM (2603:10a6:298:1::42c) To LV8PR12MB9620.namprd12.prod.outlook.com (2603:10b6:408:2a1::19) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV8PR12MB9620:EE_|MN0PR12MB5714:EE_ X-MS-Office365-Filtering-Correlation-Id: 2b5d030c-7dd1-4fce-ac11-08de9eb7ec4e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|18002099003|22082099003|56012099003; X-Microsoft-Antispam-Message-Info: YRGYcpeoD59q1ZOjz0OGddMS3i/WyHTmoKPFVWdf2vy0/ahiKlP+HNENIAVSXymGkSiKzrTPOYZtkQEosioagAw5EHbbjfZCGU45kwcwr1iOmbXU3UwshC0WnWssk/NrnCH78WNCC2ZQx9Iyu3Za8VbYn3q7MyCIdiAnYDkgHO5oJZCtjJeL5gCZA5zXwnjOalmjHgPg/p8EjCyStG19ifmwpsdcS3QOuwcsYXRhXo0DLk6P9rFkfHkO4sh4AFraRY6zDhFvgRD+pzgeZwarefwvVdT2j/tsQUaYyEwX4TZJukiQsTZfq9vnIrNbf+ZUx/Il2Zx2G/q+A2nnG+QSQE63jq+a5vFt9rXaWwVrn/8ryMrbIDJOeqE973zLXsEIWC9+TdQWjEp235lyT8Xk0exL7pWybQe82ZsDQuegdALA9JuU6LflUsA1UwJsBx3qjk7c1oN6kg1X9Tep/oaLaG9d6WNa2xbpiA+VKdFWVzHDkEh1+uRbIhMTupK3/FMVMX8qA3FBcGY0x1KMhjuNBp3akN/ZdbybegkJ86GdZBh14E09vd4E19ZZJwCdr/aD81BtpZDGKESree85dpWX64VdzZlCk/5fIqAu67CJjA/E8B0RLaGRzfIKe6N77EHvDVcf8jmq5eR+ILs88QCWQF5eHAwQAnCDvqU/FxhNdl3nQwrm+4NeBW51bEzXqFxyMxpjlOSOFN7d5GydabNFdW76lkaQGv4ua0cZfpRQH+Y= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV8PR12MB9620.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Go0N6HDPrnQYs4dB9WExyp4qtxqmZtxJIZup74AJxUaQyikkV0f1NBEaJN0I?= =?us-ascii?Q?+kqGdcJFJiqhsnj6Qbd0314a/jb2HWPbiBJnddTiwkVDEonFOzJSPPv/6g5d?= =?us-ascii?Q?obppZNXQCTgtmqsYJu3W5kzYOHxe1cz2RP5hkrGtS4VuZ6JuNi2Mz8idVbYD?= =?us-ascii?Q?2Z/Lhk7hZo6ONQ/Rl1OSHF9K3OGDUu1sEIoM6wt2fKt2a0FzSIcxf2GcME//?= =?us-ascii?Q?a8PVu3BdQIyaIv8qM+7/k1NG8xIm9Qa07iH3/DwV8156M2I1Xn7axjvqk9j5?= =?us-ascii?Q?WRdppQM5/J/g2Hhp5tvacqAijfPg1+pPAHlWyqhe+MsX5mIN/yW3ngoqlNiu?= =?us-ascii?Q?MB3gMDOBKV+r35UX+1Q3NFkdqEj1KQwVw71K15zIfnD49dinP4ZQtwpxsIi9?= =?us-ascii?Q?SJqjPtoHWNwdwx0b5Pdxg9WSPJW285jx60hTLe6SaS+QlYR0jhK+H89z3lvz?= =?us-ascii?Q?uMdpC9JNRzbOPlsyaiVPEdhSt+HhCqfmiI22/h2KbYNkfVK90+D+XddTGohN?= =?us-ascii?Q?K9lakghMXEOkotq/VDxJASq7XXlGwiyX3QKTUf5+0RvLHIFUwAgC3JX4AsmO?= =?us-ascii?Q?pzWbfJc8o11BX9d0JFuOVdZLuuQfmDkZDRZZITtcD6mkEt7wGJ0c+qKwJqDX?= =?us-ascii?Q?p8YrKOCR5CZJssOELsNzvcrbBJA3JDyZIzR2zbsEIuTtCgeHk4wYiv00JsTV?= =?us-ascii?Q?t8r58h4uxpNEXPVUcGUFkcHFcQuIytHMG547/ipKshrPPYuI0+G3w3M9+/BN?= =?us-ascii?Q?sNdrzno+XqcmDiRn4bacENtyoHbSqLGe1TPYWY7UlL2BreRu+6WbYTyXi9PE?= =?us-ascii?Q?QWuRJOHr3MEV8nM1LcZzpbYTVdfDi+Ri9qRnSd4KiYleN3ByE7uoQNHDTFIv?= =?us-ascii?Q?QmD+tnzLRYNRwNJ0IHK53jO3EnCGO1dUyRG0RF5TidiYG/WUpuIc2ixUDGah?= =?us-ascii?Q?15iTXNkWr0X00ZMkMVLSHG8DyjwLC1e+xGRIcNOo3YVQsX3OadakyhhT1qM/?= =?us-ascii?Q?HTgv077V2cvNoyxWKiHRCcfq8KNNxkYH5k9RKHynfHa9u4s6ScSF0a0Wi2GB?= =?us-ascii?Q?zU1L2LswI3n1+OwwmnvXZt5IX9urLmGi4ohK10cQyTvO2JrA27iZk9koXcru?= =?us-ascii?Q?17zpV6TAXoElVCf9cFePI+2BzkKGE4edUonxX4yW8s41hWyeVXFFaxap7iNg?= =?us-ascii?Q?V89QyMkyGOhqFCdHUN6SrjwGayHRG+4aj+wO5AE3pOeH5pexSmNeANvZEJN7?= =?us-ascii?Q?n4wAq4hLHWm7MQdYjulMQ8zYI/8SM6GxB2dAqxGvqAhFtN3FM0znPiV/HTep?= =?us-ascii?Q?L0OAROQWiwhxdU8ScFcDyYEsyBYK3tJXjWOLQ/I2QlklldBHC5zqGQkKmpMn?= =?us-ascii?Q?3MtmsqWZmkpl67ZWwC+fwd5ePrZPzd4aumidZ8FTGKR8GaWrffXACyS16mYb?= =?us-ascii?Q?2rw25BactB97RCZl75ZvBQi3h0qafwNXHFXGKQKbYaaKvqZ3mZdJ6LNc/iPl?= =?us-ascii?Q?7B9Hh7PP/VqIpsasTkjHBGAJJ7RD4PegJRFt0+C6R1XRy5+htKJfT9G0MYVl?= =?us-ascii?Q?dOBzazSwUgaCdqXBLVvRQuq74ko/4/6pYH8GSMoMyVrKnzSGnp4rCri0c7Eh?= =?us-ascii?Q?is1hvPgrf6LtTX5Xg21u0UI90HlNujUN+SJ3OVOA+OtRK9w8pZoKQN1LewMj?= =?us-ascii?Q?qODUU/uJXXsk6iY2eQThERzBOBwwj0OurUNCpNR9eKdol+u88M22nDB3RhiC?= =?us-ascii?Q?BYG/IhaOwA=3D=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b5d030c-7dd1-4fce-ac11-08de9eb7ec4e X-MS-Exchange-CrossTenant-AuthSource: LV8PR12MB9620.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2026 08:36:31.7511 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: uh4TXa1bENmHfxlesD5mIIa5fvIXJ+D74w2S1KsyXREVpp2P0HwO4cCGXy15W08XvNIxhinhAJ/VLOgkAoepXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5714 Hi Prateek, On Mon, Apr 20, 2026 at 11:19:27AM +0530, K Prateek Nayak wrote: > Hello Andrea, > > On 4/18/2026 1:54 PM, Andrea Righi wrote: > >>> @@ -7774,6 +7774,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool > >>> static int > >>> select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target) > >>> { > >>> + bool prefers_idle_core = sched_smt_active() && test_idle_cores(target); > >> > >> Somehow I miss a: > >> > >> if (prefers_idle_core) > >> set_idle_cores(target, false) > >> > >> The one in select_idle_sibling() -> select_idle_cpu() isn't executed > >> anymore in with ASYM_CPUCAPACITY. > >> > > > > Right, we need to add this as also pointed by Vincent. > > > >> > >> Another thing is that sic() iterates over CPUs sd_asym_cpucapacity > >> whereas the idle core thing lives in sd_llc/sd_llc_shared. Both sd's are > >> probably th same on your system. > > > > Hm... they're the same on my machine, but if they're different, clearing > > has_idle_cores here is not right and it might lead to false positives. We should > > only clear it only when both domains span the same CPUs (or just check if > > sd_asym_cpucapacity and sd_llc are the same). > > > > However, if they're not the same, I'm not sure exactly what we should do... > > maybe ignore has_idle_cores and always do the scan for now? > > With your changes, only two places actually care about test_idle_cores(): > > - select_idle_capacity() > - select_idle_cpu() > > If we go into select_idle_capacity(), we don't do select_idle_cpu() so > the two paths are mutually exclusive. > > In nohz_balancer_kick(), if we find, sd_asym_cpucapacity, we simply > don't care about the sd_llc_shared->nr_busy_cpus during balancing so > that begs the question if we can simply track idle_cores at > sd_asym_cpucapacity for these systems? Yeah, makes sense to me. I was planning to test something similar, so thanks for sharing this patch. :) I'll give it a try and report back. > > Following is only build tested for now but I'll try to spoof asym > cpucapacity on my system and check if it holds up or not: > > (On top of tip:sched/core at sched-core-2026-04-13 + this series) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 78f2d2c4e24f..509146c486ac 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -7913,7 +7913,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool > struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_rq_mask); > int i, cpu, idle_cpu = -1, nr = INT_MAX; > > - if (sched_feat(SIS_UTIL)) { > + if (sched_feat(SIS_UTIL) && sd->shared) { > /* > * Increment because !--nr is the condition to stop scan. > * > @@ -12856,7 +12856,8 @@ static void set_cpu_sd_state_busy(int cpu) > goto unlock; > sd->nohz_idle = 0; > > - atomic_inc(&sd->shared->nr_busy_cpus); > + if (sd->shared) > + atomic_inc(&sd->shared->nr_busy_cpus); > unlock: > rcu_read_unlock(); > } > @@ -12885,7 +12886,8 @@ static void set_cpu_sd_state_idle(int cpu) > goto unlock; > sd->nohz_idle = 1; > > - atomic_dec(&sd->shared->nr_busy_cpus); > + if (sd->shared) > + atomic_dec(&sd->shared->nr_busy_cpus); > unlock: > rcu_read_unlock(); > } > diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > index 5847b83d9d55..45b919b39c7d 100644 > --- a/kernel/sched/topology.c > +++ b/kernel/sched/topology.c > @@ -680,19 +680,38 @@ static void update_top_cache_domain(int cpu) > int id = cpu; > int size = 1; > > + sd = lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY_FULL); > + if (sd) { > + /* > + * If sd_asym_cpucapacity exists, > + * the shared object should exist too. > + */ > + WARN_ON_ONCE(!sd->shared); > + sds = sd->shared; > + } > + > + rcu_assign_pointer(per_cpu(sd_asym_cpucapacity, cpu), sd); > + > sd = highest_flag_domain(cpu, SD_SHARE_LLC); > if (sd) { > id = cpumask_first(sched_domain_span(sd)); > size = cpumask_weight(sched_domain_span(sd)); > > - /* If sd_llc exists, sd_llc_shared should exist too. */ > - WARN_ON_ONCE(!sd->shared); > - sds = sd->shared; > + /* > + * If sd_asym_cpucapacity doesn't exist, > + * sd_llc_shared must have a sd->shared linked. > + */ > + if (!sds) { > + WARN_ON_ONCE(!sd->shared); > + sds = sd->shared; > + } > } > > rcu_assign_pointer(per_cpu(sd_llc, cpu), sd); > per_cpu(sd_llc_size, cpu) = size; > per_cpu(sd_llc_id, cpu) = id; > + > + /* TODO: Rename sd_llc_shared to fit the new role. */ > rcu_assign_pointer(per_cpu(sd_llc_shared, cpu), sds); > > sd = lowest_flag_domain(cpu, SD_CLUSTER); > @@ -711,9 +730,6 @@ static void update_top_cache_domain(int cpu) > > sd = highest_flag_domain(cpu, SD_ASYM_PACKING); > rcu_assign_pointer(per_cpu(sd_asym_packing, cpu), sd); > - > - sd = lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY_FULL); > - rcu_assign_pointer(per_cpu(sd_asym_cpucapacity, cpu), sd); > } > > /* > @@ -2650,6 +2666,15 @@ static void adjust_numa_imbalance(struct sched_domain *sd_llc) > } > } > > +static void init_sched_domain_shared(struct s_data *d, struct sched_domain *sd) > +{ > + int sd_id = cpumask_first(sched_domain_span(sd)); > + > + sd->shared = *per_cpu_ptr(d->sds, sd_id); > + atomic_set(&sd->shared->nr_busy_cpus, sd->span_weight); > + atomic_inc(&sd->shared->ref); > +} > + > /* > * Build sched domains for a given set of CPUs and attach the sched domains > * to the individual CPUs > @@ -2712,16 +2737,33 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att > if (!sd) > continue; > > + /* > + * In case of ASYM_CPUCAPACITY, attach sd->shared to > + * sd_asym_cpucapacity for wakeup stat tracking. > + * > + * XXX: This assumes SD_ASYM_CPUCAPACITY_FULL domain > + * always has more than one group else it is prone to > + * degeneration. > + */ > + if (has_asym) { > + while (sd && !(sd->flags & SD_ASYM_CPUCAPACITY_FULL)) > + sd = sd->parent; > + > + init_sched_domain_shared(&d, sd); > + } > + > /* First, find the topmost SD_SHARE_LLC domain */ > + sd = *per_cpu_ptr(d.sd, i); > while (sd->parent && (sd->parent->flags & SD_SHARE_LLC)) > sd = sd->parent; > > if (sd->flags & SD_SHARE_LLC) { > - int sd_id = cpumask_first(sched_domain_span(sd)); > - > - sd->shared = *per_cpu_ptr(d.sds, sd_id); > - atomic_set(&sd->shared->nr_busy_cpus, sd->span_weight); > - atomic_inc(&sd->shared->ref); > + /* > + * Initialize the sd->shared for SD_SHARE_LLC if > + * SD_ASYM_CPUCAPACITY_FULL hasn't claimed it already. > + */ > + if (!has_asym) > + init_sched_domain_shared(&d, sd); > > /* > * In presence of higher domains, adjust the > --- > > I still have one question: Can first SD_ASYM_CPUCAPACITY_FULL be set at > a SD_NUMA? > > We'll need to deal with overlapping domains then but seems like it could > be possible with weird cpusets :-( > > But in that case, do we even want to search CPUs outside the NUMA in > select_idle_capacity()? I don't think anything stops this currently but > I might be wrong. My $0.02 on this. In theory it could happen with unusual topologies or constrained cpusets, although it should be quite rare. That said, select_idle_capacity() already operates on the span of sd_asym_cpucapacity, so if that domain crosses NUMA boundaries, we're already scanning across NUMA today. This patch doesn't fundamentally alter this behavior. If we think cross-NUMA scanning is undesirable, that's probably a more general issue in select_idle_capacity(), rather than something specific to this change and we can address this later. Thanks, -Andrea