From nobody Mon Apr 6 20:03:35 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 DFAE437FF43; Wed, 18 Mar 2026 08:08:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773821329; cv=none; b=JNRvuYHRcSy4PTJmuyWItoN0rhFwA+bYQLL/XAgD5uN5Ay/fbM36zY4+ZNQfPdGBoPjjBfWM7ysIV9G4VRS72Zs4lCSCipy8OWEelQqSCWnVp6xzYn66OITaJ11AljJ4vS7KeySA+hztdSnPdxvsgkZKgfqK5UK/hcJxiGsK0CA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773821329; c=relaxed/simple; bh=umUnaC/9+O5TAQdlY3FpJ+hAQhus/CerU1NuOHBNGyA=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=HIArlq3lROjVvX87DdqB5VACuAu15XOZY+dkoYYwfAIxRw0pwqqnq0h1Rr3N8gScRVFDorqYDAbfGoqK+0RKm+uUeu23fE+ylY7DAPNmxwAGZg8zzmd9JEhP/V1M4B//Dflja5ixys1ve7f/xpnFv0JSGAK5QWY52SnZ642cK/c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=dIKY27bb; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=eVMeVJgz; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="dIKY27bb"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="eVMeVJgz" Date: Wed, 18 Mar 2026 08:08:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1773821325; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nXlrFuqsVEYRGJoXwr+ltK2YGlpy6H7BtLUXzS1PBxE=; b=dIKY27bbyxBgh0V6nRQoT7bzVjD+lTJOJhZ4mmUV1vuUmrXmiwZTShskzFEieNL8ISpAW9 bN1iBvx5OQ/0PciS7oKAv5ZDxq7Q9yx1wTWjhJD636PtHHdN+W8WWaAm2k9W9ZXL7eOXeT 29TZFW95wiZ7kQYY7Vh1FSMFIQQirPhFlgLyy29PLGNokGjCk91s0n/MWzhbyzsiC9eNuA NUZw8Ii8/11rx22txjJHy69175qkQ94oWVvBO5YYfQn8iwLPsuPIQPHmwI787OLtKTh4jr cgbpgc1pU3cvcN6yRAXcAOh0IG/gHlmpC73vo5+LklVy/L7YGkgjNJ5IDvJOUQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1773821325; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nXlrFuqsVEYRGJoXwr+ltK2YGlpy6H7BtLUXzS1PBxE=; b=eVMeVJgzjZh8jqY6Thm98Is/TXU0ozz2uND4AQdsfOalD0zPvAIpWTJC8rFYs8pQ2KDIpY Tj+uHRcNknVZbCAg== From: "tip-bot2 for K Prateek Nayak" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/core] sched/topology: Compute sd_weight considering cpuset partitions Cc: K Prateek Nayak , "Peter Zijlstra (Intel)" , Shrikanth Hegde , Chen Yu , Valentin Schneider , Dietmar Eggemann , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20260312044434.1974-2-kprateek.nayak@amd.com> References: <20260312044434.1974-2-kprateek.nayak@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <177382132440.1647592.1849180094328011054.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The following commit has been merged into the sched/core branch of tip: Commit-ID: 8e8e23dea43e64ddafbd1246644c3219209be113 Gitweb: https://git.kernel.org/tip/8e8e23dea43e64ddafbd1246644c32192= 09be113 Author: K Prateek Nayak AuthorDate: Thu, 12 Mar 2026 04:44:26=20 Committer: Peter Zijlstra CommitterDate: Wed, 18 Mar 2026 09:06:47 +01:00 sched/topology: Compute sd_weight considering cpuset partitions The "sd_weight" used for calculating the load balancing interval, and its limits, considers the span weight of the entire topology level without accounting for cpuset partitions. For example, consider a large system of 128CPUs divided into 8 * 16CPUs partition which is typical when deploying virtual machines: [ PKG Domain: 128CPUs ] [Partition0: 16CPUs][Partition1: 16CPUs] ... [Partition7: 16CPUs] Although each partition only contains 16CPUs, the load balancing interval is set to a minimum of 128 jiffies considering the span of the entire domain with 128CPUs which can lead to longer imbalances within the partition although balancing within is cheaper with 16CPUs. Compute the "sd_weight" after computing the "sd_span" considering the cpu_map covered by the partition, and set the load balancing interval, and its limits accordingly. For the above example, the balancing intervals for the partitions PKG domain changes as follows: before after balance_interval 128 16 min_interval 128 16 max_interval 256 32 Intervals are now proportional to the CPUs in the partitioned domain as was intended by the original formula. Fixes: cb83b629bae03 ("sched/numa: Rewrite the CONFIG_NUMA sched domain sup= port") Signed-off-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Shrikanth Hegde Reviewed-by: Chen Yu Reviewed-by: Valentin Schneider Reviewed-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Link: https://patch.msgid.link/20260312044434.1974-2-kprateek.nayak@amd.com --- kernel/sched/topology.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 061f8c8..79bab80 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -1645,13 +1645,17 @@ sd_init(struct sched_domain_topology_level *tl, struct cpumask *sd_span; u64 now =3D sched_clock(); =20 - sd_weight =3D cpumask_weight(tl->mask(tl, cpu)); + sd_span =3D sched_domain_span(sd); + cpumask_and(sd_span, cpu_map, tl->mask(tl, cpu)); + sd_weight =3D cpumask_weight(sd_span); + sd_id =3D cpumask_first(sd_span); =20 if (tl->sd_flags) sd_flags =3D (*tl->sd_flags)(); if (WARN_ONCE(sd_flags & ~TOPOLOGY_SD_FLAGS, - "wrong sd_flags in topology description\n")) + "wrong sd_flags in topology description\n")) sd_flags &=3D TOPOLOGY_SD_FLAGS; + sd_flags |=3D asym_cpu_capacity_classify(sd_span, cpu_map); =20 *sd =3D (struct sched_domain){ .min_interval =3D sd_weight, @@ -1689,12 +1693,6 @@ sd_init(struct sched_domain_topology_level *tl, .name =3D tl->name, }; =20 - sd_span =3D sched_domain_span(sd); - cpumask_and(sd_span, cpu_map, tl->mask(tl, cpu)); - sd_id =3D cpumask_first(sd_span); - - sd->flags |=3D asym_cpu_capacity_classify(sd_span, cpu_map); - WARN_ONCE((sd->flags & (SD_SHARE_CPUCAPACITY | SD_ASYM_CPUCAPACITY)) =3D= =3D (SD_SHARE_CPUCAPACITY | SD_ASYM_CPUCAPACITY), "CPU capacity asymmetry not supported on SMT\n");