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 09E363ACEF2 for ; Tue, 24 Mar 2026 08:08:27 +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=1774339716; cv=none; b=JoC6/bay6VihkC6uxwdtzrtK9VetOV55IdkwE+tB1irRF1EYa+tclaPyvHVyVxpC0abx1RrkiLGfbjaaAycOPzBOoOql3WwNB8NiPlxWv8NVnt9YnMnRv7laixP43ag+0v9r91H1HY66mzClowrscA8I/1mN1qS0x0SRgWMol0Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774339716; c=relaxed/simple; bh=P1iZNzbZreyRU8TOh3LHs/Ci/LC0ULgb1lniECRJUzU=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=DVyfhxFpRwX/XYNfhRws46Qoqso2DINZ4MZ5++tVJPt21spUon6YSbYGCpIKoEYz7IQlg3sI1CSh0rsZod+fRowgMUM5yzmfiZy+VB2DKH+tBMPkVx834k0ZH1uaLWZSPXlx5RbawZ/sIJDteJjFpUfdgwc19istW3leVtYgfVc= 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 BFE681476; Tue, 24 Mar 2026 01:08:20 -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 AE3D63F63F; Tue, 24 Mar 2026 01:08:23 -0700 (PDT) Message-ID: Date: Tue, 24 Mar 2026 08:08:22 +0000 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 From: Christian Loehle To: Vincent Guittot , Andrea Righi Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org, Felix Abecassis References: <20260324005509.1134981-1-arighi@nvidia.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: >>> >>> 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. Also, given that this patch even mentions this as "noise" one might ask why the firmware wouldn't force-equalise this. Anyway let me finally send out those asympacking patches which would make that issue obsolete because we actually make use of the highest_perf information from the firmware. > >> [snip] >