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 07F10211A28 for ; Wed, 1 Apr 2026 11:57:11 +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=1775044634; cv=none; b=faLp6fO9nadPRI10pRiuv05Ny864RXTqVxoRxOorSWdM+NQ4oSoLcU8Tj++V326tNBkTjFUi6j5yziANGAuGyC1bRHFIfjRTQnelRcZetFnXpB258pXhcMHrxJQ88sMmYsRLZnyyJixicEWZKcLMkIzXd3I7Zqvg3YxbtlY+nVo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775044634; c=relaxed/simple; bh=b1uX5asl6MNaCRpvx0Rl1wdz8HBd0nSAl4K/LdJzXLY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=i+uRz4g3vbKrDjYdRngtlbC3/Ter/RLgqXJFirRSz7GJflhqHzS0v+C83VMx0FreununRx4H3LvyotrZjC85iROweMWV5aWXegj88tFbm5fAQae/o02a1DQxGVxZIyORq8sDJk1c5HQ6wflHY5l+QJuNL/vdCTrnlHZLd7JdHuo= 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=jTY9HvXM; 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="jTY9HvXM" 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 5B86F1688; Wed, 1 Apr 2026 04:57:05 -0700 (PDT) Received: from [192.168.178.100] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4DCBA3F7D8; Wed, 1 Apr 2026 04:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775044631; bh=b1uX5asl6MNaCRpvx0Rl1wdz8HBd0nSAl4K/LdJzXLY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jTY9HvXMZcg29Z7TMGN5v6R/lV4dCwEbzWKRdgVW+hU1084/rcCpB2+yvQm62LP6y HtkGpSE+LY5LBZCa9YNDkZUkUWqNyy/Fv0oA9z3P3XZFey14klgNSiWTqWWkzZ9taO HW9BiB++Daz5IuqzzPTKEryJ12BgtLYcEYImqmJM= Message-ID: <193f1cd1-ced3-4b37-83af-ea43a7e5e3d0@arm.com> Date: Wed, 1 Apr 2026 13:57:08 +0200 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 0/4] sched/fair: SMT-aware asymmetric CPU capacity To: Andrea Righi Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Christian Loehle , Koba Ko , Felix Abecassis , Balbir Singh , linux-kernel@vger.kernel.org References: <20260326151211.1862600-1-arighi@nvidia.com> Content-Language: en-GB From: Dietmar Eggemann In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 31.03.26 11:04, Andrea Righi wrote: > Hi Dietmar, > > On Tue, Mar 31, 2026 at 12:30:55AM +0200, Dietmar Eggemann wrote: >> Hi Andrea, >> >> On 26.03.26 16:02, Andrea Righi wrote: [...] >> So does (2) with NO_SIS_UTIL performs worse than (1) with your smt >> related add-ons in sic()? > > Thanks for running these experiments and sharing the data, this is very > useful! > > I did a quick test on Vera using the NVBLAS benchmark, comparing NO > ASYM_CPUCAPACITY with and without SIS_UTIL, but the difference seems to be > within error range. I'll also run DCPerf MediaWiki with all the different I'm not familiar with the NVBLAS benchmark. Does it drive your system into 'sd->shared->nr_idle_scan = 0' state? We just have to understand where this benefit of using sic() instead of sis() is coming from. I'm doubtful that this is the best_cpu thing after if (!choose_idle_cpu(cpu, p)) in sic()'s for_each_cpu_wrap(cpu, cpus, target) loop given that the CPU capacity diffs are so small. > configurations to see if I get similar results. > > More in general, I agree that for small capacity differences (e.g., within > ~5%) the benefits of using ASYM_CPUCAPACITY is questionable. And I'm also > fine to go back to the idea of grouping together CPUS within the 5% > capacity window, if we think it's a safer approach (results in your case > are quite evident, and BTW, that means we also shouldn't have > ASYM_CPU_CAPACITY on Grace, so in theory the 5% threshold should also > improve performance on Grace, that doesn't have SMT). There shouldn't be so many machines with these binning-introduced small CPU capacity diffs out there? In fact, I only know about your Grace (!smt) and Vera (smt) machines. > That said, I still think there's value in adding SMT awareness to > select_idle_capacity(). Even if we decide to avoid ASYM_CPUCAPACITY for > small capacity deltas, we should ensure that the behavior remains > reasonable if both features are enabled, for any reason. Right now, there > are cases where the current behavior leads to significant performance > degradation (~2x), so having a mechanism to prevent clearly suboptimal task > placement still seems worthwhile. Essentially, what I'm saying is that one > thing doesn't exclude the other. IMHO, in case we would know where this improvement is coming from using sic() instead of default sis() (which already as smt support) then maybe, it's a lot of extra code at the end ... And mobile big.LITTLE (with larger CPU capacity diffs) doesn't have smt.