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 26FC436E462 for ; Fri, 3 Apr 2026 11:47:19 +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=1775216841; cv=none; b=SULQW38JbpSdwWZucWiSSHcW5UWtm4+6DFOTUC+AQhm/vo6Qg/1cmlm7LYa9vvV1ZbZ/Rn5qcc+UAu2jHIjSaIhLfTtO7rWgivb873iHx5kVIW6FuluWVIyb/YvY9rTd5AtZ6L+6rfCjcokin1mj0Yk25dArS7g2rBRcCoQ5eKc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775216841; c=relaxed/simple; bh=Xu/2zhx8kmew6WO02idv8+QIKj2a+6VsltsR1O8kWlI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fOs6sJsp+kSP5NlQaV5jO5KkexAheQDitTd3yjyAlFqdAQCOx1Z0rUC17ez+RywFOzI8GcbVPt5dnOFEh1iKkxA7BEezvfpb53ZurSBwKdrp1R0wPhsxkmP67Eop5l/WWdCyQtcuOfDVEIak/wwxlnG+pYYNR/3JXpyuwjgyr4o= 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=T/ZCL4ne; 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="T/ZCL4ne" 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 A60853555; Fri, 3 Apr 2026 04:47:13 -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 3D4063F641; Fri, 3 Apr 2026 04:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775216839; bh=Xu/2zhx8kmew6WO02idv8+QIKj2a+6VsltsR1O8kWlI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=T/ZCL4neNRtZdm2IzlVZKS5Bg9Fmfwqz3wF0IFF/d48ZABIRxKT/z8gWfYZONy2NO C84ssLTfNdX3cygAWbHtA7oSEZytRmLHStpqbLuzUh99pDY0H0tAGP2zf3H55EHtvA SdFFDmdLQzTQPjWwL6rPaZxYbqzgFTacyhk0vmDg= Message-ID: <9886a7d3-fb54-4637-8b4c-1f35272f4882@arm.com> Date: Fri, 3 Apr 2026 13:47:17 +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 15:12, Andrea Righi wrote: > On Wed, Apr 01, 2026 at 02:42:34PM +0200, 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: [...] > Just finished running some tests with DCPerf MediaWiki on Vera as well > (sorry, it took a while, I did mutliple runs to rule out potential flukes): > > +---------------------------------+--------+--------+--------+--------+ > | Configuration | rps | p50 | p95 | p99 | Just to make sure: rps -> "Wrk RPS" and pXX -> "Nginx PXX time" in run_details.json ? > +---------------------------------+--------+--------+--------+--------+ > | NO ASYM + SIS_UTIL | 8113 | 0.067 | 0.184 | 0.225 | > | NO ASYM + NO_SIS_UTIL | 8093 | 0.068 | 0.184 | 0.223 | Thanks for the test results! Ok, so SIS_UTIL doesn't seem to play a role here. This workload should have #runnable tasks > #CPUs. Still trying to grasp why 'sic() + smt' is better than 'sis() + smt' for NVBLAS? There is a subtle differences in the start cpu for iterating: sis(): for_each_cpu_wrap(cpu, cpus, target + 1) ^^^ sic(): for_each_cpu_wrap(cpu, cpus, target) Not sure if this makes all the difference? > | | | | | | > | ASYM + SMT + SIS_UTIL | 8129 | 0.076 | 0.149 | 0.188 | > | ASYM + SMT + NO_SIS_UTIL | 8138 | 0.076 | 0.148 | 0.186 | This should be the same, right? SIS_UTIL is only for sis() so when using sic() this shouldn't differ. Or did you code SIS_UTIL into sic()? > | | | | | | > | ASYM + ILB SMT + SIS_UTIL | 8189 | 0.075 | 0.150 | 0.189 | > | ASYM + SMT + ILB SMT + SIS_UTIL | 8185 | 0.076 | 0.151 | 0.190 | > +---------------------------------+--------+--------+--------+--------+ So with '#tasks > #CPUs' smt doesn't make a difference. > Looking at the data: > - SIS_UTIL doesn't seem relevant in this case (differences are within > error range), > - ASYM_CPU_CAPACITY seems to provide a small throughput gain, but it seems > more beneficial for tail latency reduction, > - the ILB SMT patch seems to slightly improve throughput, but the biggest > benefit is still coming from ASYM_CPU_CAPACITY. > Overall, also in this case it seems beneficial to use ASYM_CPU_CAPACITY > rather than equalizing the capacities. > > That said, I'm still not sure why ASYM is helping. The frequency asymmetry OK, I still would be more comfortable with this when I would now why this is :-) > is really small (~2%), so the latency improvements are unlikely to come > from prioritizing the faster cores, as that should mainly affect throughput > rather than tail latency and likely to a smaller extent. [...]