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 2D2E2379975 for ; Fri, 3 Apr 2026 11:47: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=1775216837; cv=none; b=rcU8vBOMmIgO/sSCWD3tUMsDSt0CxX6+a+Cri10DTTFkY1d+Rsq3+tRw+IPeNrcyf9rtZriILHhPMtB/zLaT1vGufKuh7PZuMXUjNYUTUJJzdPSMAMJLKOS0/HuahaBKX8KqIv2WRMDjRiP+/Ks2Mo5QQb2u7a9+jOAn6oKZ+94= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775216837; c=relaxed/simple; bh=vgtyGoqF2gowYK2fEGoCYLK7lmDhq0RNRRxRxMT7g78=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mc5V/I2K41o9y1g1kaa0UNnxWkBZrNQNq4eIiSm3GQRm923/l092oI3ibScW7P7rkTOB3OkaD3p8GTNCU972n6dZflry9FTp7I1QUzBtDcZwUwpHXVOrH0YMMNOJw5bolQdMt3IujbYV9O1fjS0Bw2nOI94dysesM01XuFrl5C8= 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=JUwkbbXT; 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="JUwkbbXT" 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 1F088351B; Fri, 3 Apr 2026 04:47:08 -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 AC2F83F641; Fri, 3 Apr 2026 04:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775216833; bh=vgtyGoqF2gowYK2fEGoCYLK7lmDhq0RNRRxRxMT7g78=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=JUwkbbXTGw00+S3BcIu17QmUm92y+rauhEB0tUIEbhnez0JPmAUvgUHG+fG5ZZ0Gc Hg4L8IW4cZjXPK9u2ODlKJnefBECS0tGppCcHrIiP0e5MVPExuMgYuc8XQxU8+Uzlm I7jiO3KyxjsW2bciAk3bBuHItwBUax2SLf261wBg= Message-ID: <973b57e8-ad07-4804-8d30-36c607fb3332@arm.com> Date: Fri, 3 Apr 2026 13:47:10 +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 , Vincent Guittot Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , 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> <193f1cd1-ced3-4b37-83af-ea43a7e5e3d0@arm.com> Content-Language: en-GB From: Dietmar Eggemann In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.04.26 14:42, Andrea Righi wrote: > On Wed, Apr 01, 2026 at 02:08:27PM +0200, Vincent Guittot wrote: >> On Wed, 1 Apr 2026 at 13:57, Dietmar Eggemann wrote: >>> >>> 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: [...] >>>> 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 Ah, but this benchmark with '#tasks == #cores' is tailored for this prefer_core thing. And SIS_UTIL shouldn't close the idle CPU search. >>> I'm not familiar with the NVBLAS benchmark. Does it drive your system >>> into 'sd->shared->nr_idle_scan = 0' state? > > It's something internally unfortunately... it's just running a single > CPU-intensive task for each SMT core (in practice half of the CPUs tasks). > I don't think we're hitting sd->shared->nr_idle_scan == 0 in this case. OK. >>> 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. >> >> In any case it's always better to add the support than enabling asym_packing Yeah, the question for me is more between existing 'sis() + smt' or this new 'sic() + smt' with those minor CPU capacity differences. [...] >>> 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. >> >> The last proposal based on prateek proposal in sic() doesn't seems that large > > Exactly, I was referring just to that patch, which would solve the big part > of the performance issue. We can ignore the ILB part for now. OK, I see. It's in your v2 you sent out earlier today so I will comment there.