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 8B9D73BC670 for ; Tue, 24 Mar 2026 10:29:37 +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=1774348180; cv=none; b=URtPRb54eoZg1vSf1Dd4WJAs28MHTGfJzY3WOcj8Nre5amXOGCUCPtWgt0tPmPeWwUKGghQd2ukLabqimaqbJ9IkbbB2utUK/SmFktTLWu1bP4aAtGa0eRNjHymZpN0B2qbxDvSSCkz+WmKk1Cw/IEoBcZh/HIeMAgcZDPGobSI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774348180; c=relaxed/simple; bh=UJtAMVDNzeleIb/7lWb71zrOu0LMI0tY6IU7vKcON5M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=o5pi+FBRpU6eVP4cdFk6sp/EtgDoFa5qY/t0TUx5aD10zSsaytk7FrSC8oOZiERCM4fbvWPBW3RpvENcRWA62waeij8nH2aBjT1163PV3ndFfQSFbihwDb5qMULr9YrE75Z5UORNioJiF6AB4BqY9sJYQI1250qoTDqQHv3katA= 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 DD3AC1476; Tue, 24 Mar 2026 03:29:30 -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 49B7A3FDF5; Tue, 24 Mar 2026 03:29:34 -0700 (PDT) Message-ID: <0fb05951-1f2f-474f-9f7c-9f0f15a5f675@arm.com> Date: Tue, 24 Mar 2026 11:29:24 +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 , Christian Loehle Cc: 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> Content-Language: en-GB From: Dietmar Eggemann In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: [...] >>>> 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. > > I think it's reasonable to consider that as "noise" from a scheduler > perspective, but from a hardware/firmware point of view I don't have strong > arguments to propose equalizing the highest_perf values. At the end, at > least in my case, it seems all compliant with the ACPI/CPPC specs and > suggesting to equalize them because "the kernel doesn't handle it well" > doesn't seem like a solid motivation... The first time we observed this on NVIDIA Grace, we wondered whether there might be functionality outside the task scheduler that makes use of these slightly heterogeneous CPU capacity values from CPPC—and whether the dependency on task scheduling was simply an overlooked phenomenon. And then there was DCPerf Mediawiki on 72 CPUs system always scoring better with sched_asym_cpucap_active() = TRUE (mentioned already by Chris L. in: https://lore.kernel.org/r/15ffdeb3-a0f3-4b88-92c0-17ffb03b0574@arm.com >> 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. > > Looking forward to that. :) > > Thanks, > -Andrea