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 53A9422D7B9 for ; Wed, 25 Mar 2026 15:26:48 +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=1774452409; cv=none; b=NBWATzLGt+fDYm6aqRAyVTLFIfoe5qbU8ZRgqe/Zdz++7V3YplLnMs9RZiXz+OYYY73mv29bAPiCHtLY4zRolXyYpuuwgdPkZO9ZjJcB3EnTGAvnkyt2M6fHYqP5N3966YxRPBfvMasNKFRyGE+hWiMZKySVY7q8O1YFhyTE9xU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774452409; c=relaxed/simple; bh=PziZyF2AGfmi8cCFL+5wNjyy1bfNn+m8aMS0LwhHiZ4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XTZgX/0VcVM9PejPxNxn4dXnIVC4kOOlX0yNAcd8fy4XS+PPxj6mdwfDZ4GH/j1DZb54QQZIhc3qZtl59RZ0zdvBKxteXiz0xGn32uKyOiR2vwGpkhydMkC/D0D1wZ4lRoZAsWfxVbC14T/fOyH35hxjaD7Aq6pzpkTHGttZeCw= 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=QHmpsgop; 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="QHmpsgop" 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 6BEFE1E8D; Wed, 25 Mar 2026 08:26:41 -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 97E793F915; Wed, 25 Mar 2026 08:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774452407; bh=PziZyF2AGfmi8cCFL+5wNjyy1bfNn+m8aMS0LwhHiZ4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=QHmpsgopDt9o0XmpFejgMh5Khs5nbGNhwUd9+u+ruY1ZaglpIixlDe8TU2pODKtbp bZDbQbpA8AgsvlYdeACyRdjZTPS3Yy3hOaTaKpzMwtcJbZcXXQuBp52rlzNeXgGjOF iDJ4StoIq4GsKrFgqyb2KfzbqPFkV/WoKrvWkGcQ= Message-ID: <9102f6e4-2360-4999-a036-c92cd039e5d4@arm.com> Date: Wed, 25 Mar 2026 16:26:44 +0100 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] sched/topology: Avoid spurious asymmetry from CPU capacity noise To: Andrea Righi Cc: Christian Loehle , Vincent Guittot , Ingo Molnar , Peter Zijlstra , Juri Lelli , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org, Felix Abecassis References: <20260324005509.1134981-1-arighi@nvidia.com> <0fb05951-1f2f-474f-9f7c-9f0f15a5f675@arm.com> <86cb3979-02cd-4171-80fd-df20cb3430cb@arm.com> <1d9b4abf-4b70-4775-92b8-924ced316578@arm.com> From: Dietmar Eggemann Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 25.03.26 13:25, Andrea Righi wrote: > On Wed, Mar 25, 2026 at 12:16:59PM +0100, Dietmar Eggemann wrote: >> On 25.03.26 10:32, Andrea Righi wrote: >>> On Wed, Mar 25, 2026 at 10:23:09AM +0100, Dietmar Eggemann wrote: >>>> On 24.03.26 12:01, Andrea Righi wrote: >>>>> Hi Dietmar, >>>>> >>>>> On Tue, Mar 24, 2026 at 11:29:24AM +0100, Dietmar Eggemann wrote: >>>>>> On 24.03.26 10:46, Andrea Righi wrote: >>>>>>> Hi Christian, >>>>>>> >>>>>>> On Tue, Mar 24, 2026 at 08:08:22AM +0000, Christian Loehle wrote: >>>>>>>> On 3/24/26 07:55, Christian Loehle wrote: >>>>>>>>> On 3/24/26 07:39, Vincent Guittot wrote: >>>>>>>>>> On Tue, 24 Mar 2026 at 01:55, Andrea Righi wrote: [...] > Exactly, we already prefer fully-idle cores over partially-idle cores with > asym-capacity disabled, but in that case the idle selection logic stays in > a world of idle bits, without cap/util math, so it's a bit easier. And it's > probably fine also when we have both asym-capacity + SMT (at least it seems > better than what we have now, ignoring the SMT part). > > Essentially having somethig like the following (which already gives better > performance on Vera): > > kernel/sched/fair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index d57c02e82f3a1..534634f813fca 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -8086,7 +8086,7 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target) > * For asymmetric CPU capacity systems, our domain of interest is > * sd_asym_cpucapacity rather than sd_llc. > */ > - if (sched_asym_cpucap_active()) { > + if (sched_asym_cpucap_active() && !sched_smt_active()) { > sd = rcu_dereference_all(per_cpu(sd_asym_cpucapacity, target)); > /* > * On an asymmetric CPU capacity system where an exclusive Ah, I thought we were talking !sched_asym_cpucap_active() case, either by letting CPPC return the same value for all CPUs or by introducing this 20%/5% threshold into asym_cpu_capacity_scan(). ASYM_CPUCAP + SHARE_CPUCAP vs SHARE_CPUCAP would still behave slightly differently because of asym_fits_cpu() in all those early bailout conditions (1) in sis(). select_idle_sibling() if (choose_idle_cpu(target, p) && asym_fits_cpu(task_util, util_min, util_max, target)) <-- (1) return target; ... And you would still have misfit_task load balance enabled. Those subtle differences may influence behavior compared to a simpler homogeneous CPU capacity model, but it’s unclear whether they justify introducing yet another variant alongside the existing homogeneous and fully heterogeneous (non-SMT) approaches. IMHO, we should only consider allowing this if there is clear evidence of significant benefits across a representative range of benchmarks and workloads. [...]