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 7EA86359A62
	for <linux-kernel@vger.kernel.org>; Tue, 24 Mar 2026 07:55:26 +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=1774338934; cv=none; b=IwolrS04wXWNQHaTH7khAYtFcx9j90DeKLP7EUlBeQusEsijCQK6JBU6M/L5svntajoFyiWu8XHTk6W21+EGD6f4y62kWRyPQ56opQKCF6QxcwLhtfHB0uZHKkCz/BqGo3yVGSEUbBsu6qGzOobs1ppjpMCIGJtcYSTnZWVPOrE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1774338934; c=relaxed/simple;
	bh=AF68jnPFX5t7GTH5xyKOGtZeKyfHqyio938KmzU9wxQ=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=UauDQ0LjOPsOwzShKd5Oe4VqiCHcySJf6gh3x4sRzZBYB9yINzbrHjRiFC9/Kz/uUR/FrpDvMfl28jyvjQ2JsSAtYl/DvON2l/FZz3g8FQ7BkohjEgsl3yY514mt8cmiAqhAaaOXj5U0JT2rC5SK/3kQu3donM/EePJHeKoQWbM=
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; 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
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 AD5661476;
	Tue, 24 Mar 2026 00:55:19 -0700 (PDT)
Received: from [10.1.32.16] (unknown [10.1.32.16])
	by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6D4393F694;
	Tue, 24 Mar 2026 00:55:23 -0700 (PDT)
Message-ID: <cbdb72fa-e9b1-45dd-a372-a5ced4966469@arm.com>
Date: Tue, 24 Mar 2026 07:55:20 +0000
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] sched/topology: Avoid spurious asymmetry from CPU
 capacity noise
To: Vincent Guittot <vincent.guittot@linaro.org>,
 Andrea Righi <arighi@nvidia.com>
Cc: Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
 Juri Lelli <juri.lelli@redhat.com>,
 Dietmar Eggemann <dietmar.eggemann@arm.com>,
 Steven Rostedt <rostedt@goodmis.org>, Ben Segall <bsegall@google.com>,
 Mel Gorman <mgorman@suse.de>, Valentin Schneider <vschneid@redhat.com>,
 linux-kernel@vger.kernel.org, Felix Abecassis <fabecassis@nvidia.com>
References: <20260324005509.1134981-1-arighi@nvidia.com>
 <CAKfTPtBYdwNGw1QHPABVgz5KX+rzWv=f1V8Kgde7CU1yX10g8A@mail.gmail.com>
Content-Language: en-US
From: Christian Loehle <christian.loehle@arm.com>
In-Reply-To: <CAKfTPtBYdwNGw1QHPABVgz5KX+rzWv=f1V8Kgde7CU1yX10g8A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 3/24/26 07:39, Vincent Guittot wrote:
> On Tue, 24 Mar 2026 at 01:55, Andrea Righi <arighi@nvidia.com> wrote:
>>
>> On some platforms, the firmware may expose per-CPU performance
>> differences (e.g., via ACPI CPPC highest_perf) even when the system is
>> effectively symmetric. These small variations, typically due to silicon
>> binning, are reflected in arch_scale_cpu_capacity() and end up being
>> interpreted as real capacity asymmetry.
>>
>> As a result, the scheduler incorrectly enables SD_ASYM_CPUCAPACITY,
>> triggering asymmetry-specific behaviors, even though all CPUs have
>> comparable performance.
>>
>> Prevent this by treating CPU capacities within 20% of the maximum value
> 
> 20% is a bit high, my snapdragon rb5 has a mid CPU with a capacity of
> 871 but we still want to keep them different
> 
> Why would 5% not be enough?

I've also used 5%, or rather the existing capacity_greater() macro.

>[snip]