From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 062DD3A3E95 for ; Tue, 7 Apr 2026 11:21:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775560882; cv=none; b=Q41hniCxJLEPPnup5MOOi89j8VfL1+uGivT3v59FPJXVVFFUh9M9+EBfXhkf01Mn05U1VqDddZ8A667RaG7WFBUZGsBhaI92VQcAR/wbtz++vCbDHAdJyylpZaoDZnU1OQcu3P8dbR2I+evR7EpQAix7sQiwRmUvl7jwBdFl20E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775560882; c=relaxed/simple; bh=h4KcsZS29Sop+0GrunMH14EEdgGB8Au4f2b6jOBdefQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ntdSgmvD+y5tcxQheCqziEyMLJaBRfHKd9GH8NxddaoJhhgEHKH6ZuIr8yX8BQOgTayWE1llo1p62+74P56qZWWCmfJN54KOjy31XTc5B7tO2E0qgYi7OhFVPfyJWILTRlyzI5Uh8seJi+sZSw9bghS94Vv2eGtW5EThQHoK5Ys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=stjJnpur; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="stjJnpur" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A2AB41BB0; Tue, 7 Apr 2026 04:21:14 -0700 (PDT) Received: from [192.168.178.6] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1E3353F7D8; Tue, 7 Apr 2026 04:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775560880; bh=h4KcsZS29Sop+0GrunMH14EEdgGB8Au4f2b6jOBdefQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=stjJnpurQkhVfRJur/AqIPBrXzxlLKauxFuxytuLE6VmID0br98TikKs5QEijsMHg W0nek4G0v6Szb9p8Dy4Hh+SUzyjXz/7WImhYx9O0nQ6sBjj1ZFxH8Ur244Pfpydy8L UAn2U+RYYJNqvbHCC78SgIsOb0/HG1Sz6YaTpROc= Message-ID: <64fe32e0-d428-42bb-beb4-2656d8781b0f@arm.com> Date: Tue, 7 Apr 2026 13:21:16 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection To: Andrea Righi , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot Cc: Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Christian Loehle , Koba Ko , Felix Abecassis , Balbir Singh , Shrikanth Hegde , linux-kernel@vger.kernel.org References: <20260403053654.1559142-1-arighi@nvidia.com> <20260403053654.1559142-2-arighi@nvidia.com> Content-Language: en-GB From: Dietmar Eggemann In-Reply-To: <20260403053654.1559142-2-arighi@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03.04.26 07:31, Andrea Righi wrote: > On systems with asymmetric CPU capacity (e.g., ACPI/CPPC reporting > different per-core frequencies), the wakeup path uses > select_idle_capacity() and prioritizes idle CPUs with higher capacity > for better task placement. > > However, when those CPUs belong to SMT cores, their effective capacity > can be much lower than the nominal capacity when the sibling thread is > busy: SMT siblings compete for shared resources, so a "high capacity" > CPU that is idle but whose sibling is busy does not deliver its full > capacity. This effective capacity reduction cannot be modeled by the > static capacity value alone. > > When SMT is active, teach asym-capacity idle selection to treat a > logical CPU as a weaker target if its physical core is only partially > idle: select_idle_capacity() no longer returns on the first idle CPU > whose static capacity fits the task when that CPU still has a busy > sibling, it keeps scanning for an idle CPU on a fully-idle core and only > if none qualify does it fall back to partially-idle cores, using shifted > fit scores so fully-idle cores win ties; asym_fits_cpu() applies the > same fully-idle core requirement when asym capacity and SMT are both > active. > > This improves task placement, since partially-idle SMT siblings deliver > less than their nominal capacity. Favoring fully idle cores, when > available, can significantly enhance both throughput and wakeup latency > on systems with both SMT and CPU asymmetry. > > No functional changes on systems with only asymmetric CPUs or only SMT. > > Cc: K Prateek Nayak > Cc: Vincent Guittot > Cc: Dietmar Eggemann > Cc: Christian Loehle > Cc: Koba Ko > Reported-by: Felix Abecassis > Signed-off-by: Andrea Righi > --- > kernel/sched/fair.c | 36 ++++++++++++++++++++++++++++++++---- > 1 file changed, 32 insertions(+), 4 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index bf948db905ed1..7f09191014d18 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -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. 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. > unsigned long task_util, util_min, util_max, best_cap = 0; > int fits, best_fits = 0; > int cpu, best_cpu = -1; [...]