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 5064A3148D9 for ; Wed, 25 Mar 2026 09:23:14 +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=1774430596; cv=none; b=bCrJkJ3nCQG09LWY+kEidjL7Y0Hhq8hv/GTmw+ysawtAM3tO2+BIaVFoGrqXfuGiRTC0pdpsRNlnBS+WClUr9y1uRQvh/o5bzXxRqMkuzV/HOCPDmvvqGZZ+G91vpJGARy/7OsA/yOe/hxkirOWGNHYpeRVO5y5lM7JlGxErpiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774430596; c=relaxed/simple; bh=nJymjNc4p5q0U4uIt5dR01fX1sh1EwBOc0aWhMVhRnI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aaHY9ARISzJdh8+oXTmjdxcz+z+iitc6n2Hpgt6Uk195dFJtmVkS8d5gUadHrm77bdFdcbChOWLnTYC6W30W6Da0viIkVV3QssHZ4cGtLqdODBdjinDFzs1AGQHuaI5sHhcWPvQasJ6vD/CZb3qlXuuZzICb7PAGkpM0pU/+0iQ= 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=WrryCO/m; 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="WrryCO/m" 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 5449714BF; Wed, 25 Mar 2026 02:23:07 -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 2F5263F836; Wed, 25 Mar 2026 02:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774430593; bh=nJymjNc4p5q0U4uIt5dR01fX1sh1EwBOc0aWhMVhRnI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=WrryCO/mN/EXQqPMBebLgLVXKiiioARk47dZrkPIjwvZl4q6jikvbAAj+sz6BqU3w zZ5QXe69k8g9xsF9AK7oF2tj5O8WeN9RVBlmfBDxqhX+qJQ5DQwfAFHNM5EJON0FGP I3An+LIkx07YUBSyibyylL9/JNW3AYJDggAzvdsU= Message-ID: <86cb3979-02cd-4171-80fd-df20cb3430cb@arm.com> Date: Wed, 25 Mar 2026 10:23:09 +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> From: Dietmar Eggemann Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: [...] >> 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 > > Yeah, I think Chris' asym-packing approach might be the safest thing to do. > > At the same time it would be nice to improve asym-capacity to introduce > some concept of SMT awareness, that was my original attempt with > https://lore.kernel.org/all/20260318092214.130908-1-arighi@nvidia.com, > since we may see similar asym-capacity benefits on Vera (that has SMT, > unlike Grace). What do you think? We never found a good way to specify a CPU capacity in the SMT case (EAS and energy model included). So comparing CPU capacity w/ utilization, CPU overutilization detection etc. definitions get more blurry. But in case you now want to hide these small CPU capacity differences from asym-cpucap setup you won't run into this 'SD_SHARE_CPUCAPACITY + SD_ASYM_CPUCAPACITY'. You still will have small differences in sched group capacities but this is covered by load-balance. BTW, you should have seen on Vera ?: sd_int() [kernel/sched/.topology.c] 1720 WARN_ONCE((sd->flags & (SD_SHARE_CPUCAPACITY | SD_ASYM_CPUCAPACITY)) == 1721 (SD_SHARE_CPUCAPACITY | SD_ASYM_CPUCAPACITY), 1722 "CPU capacity asymmetry not supported on SMT\n");