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 8D10A413249 for ; Thu, 26 Mar 2026 16:33:13 +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=1774542795; cv=none; b=aimEpratOBETSBuae1ung6TUwZ1/tkL4U5C62Z8gA+DUV4JqkTKSS/rtOq+HSjWhrBA8KK2ENI5lNiU/9bIv/AlZPEIyyZhn4N+1GI0K+BIudCH44bSR34gM4ol9apADLAZomm1zNPgO5V31OevavztiHgPYzq0kefchsgH9nEE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774542795; c=relaxed/simple; bh=ZJVRHfnJmOkT59fN3zZly5bGtfN/zHVsw6mg7qJrP6I=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nItnfzTt7PcgSSwtYs+EI+38lAeeT/nLl3qYtLj2lYLhFuZMqaG9fNAehni89/GSmq4AutUKQINVjHOYV99eL+z4S2GGIvL55q7l90lLP/R8SVjh5RJVb4FIPD3ycGSPZj+U4zDRzRvfCu4CKxaV8f5vr0UCxzbxSUftdhiw58E= 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=jCINCRVh; 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="jCINCRVh" 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 F0E072BC0; Thu, 26 Mar 2026 09:33:06 -0700 (PDT) Received: from [10.57.20.244] (unknown [10.57.20.244]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4913E3F905; Thu, 26 Mar 2026 09:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774542792; bh=ZJVRHfnJmOkT59fN3zZly5bGtfN/zHVsw6mg7qJrP6I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jCINCRVhf3Rr5gpAmTFXICVTdY6WmmlNDjllWOu+6SS8Fz3zqUYZH+ctDuGGY2kFl TjbRdYlq2FTlWyufRFRyQlR+0nQgzmtuplUU0qMTUAvymJ4gIdcxaGuGKKnvpjBrnG Eq2UyPY7QOAOQ5lK8+lMaNbmtfE4LWdzpP6cWX40= Message-ID: <8b052854-36a5-4a5a-be32-ed2ce245a117@arm.com> Date: Thu, 26 Mar 2026 16:33:08 +0000 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 , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Koba Ko , Felix Abecassis , Balbir Singh , linux-kernel@vger.kernel.org References: <20260326151211.1862600-1-arighi@nvidia.com> Content-Language: en-US From: Christian Loehle In-Reply-To: <20260326151211.1862600-1-arighi@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/26/26 15:02, Andrea Righi wrote: > This series attempts to improve SD_ASYM_CPUCAPACITY scheduling by > introducing SMT awareness. > > = Problem = > > Nominal per-logical-CPU capacity can overstate usable compute when an SMT > sibling is busy, because the physical core doesn't deliver its full nominal > capacity. So, several SD_ASYM_CPUCAPACITY paths may pick high capacity CPUs > that are not actually good destinations. > > = Proposed Solution = > > This patch set aligns those paths with a simple rule already used > elsewhere: when SMT is active, prefer fully idle cores and avoid treating > partially idle SMT siblings as full-capacity targets where that would > mislead load balance. > > Patch set summary: > > - [PATCH 1/4] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection > > Prefer fully-idle SMT cores in asym-capacity idle selection. In the > wakeup fast path, extend select_idle_capacity() / asym_fits_cpu() so > idle selection can prefer CPUs on fully idle cores, with a safe fallback. > > - [PATCH 2/4] sched/fair: Reject misfit pulls onto busy SMT siblings on asym-capacity > > Reject misfit pulls onto busy SMT siblings on SD_ASYM_CPUCAPACITY. > Provided for consistency with PATCH 1/4. > > - [PATCH 3/4] sched/fair: Enable EAS with SMT on SD_ASYM_CPUCAPACITY systems > > Enable EAS with SD_ASYM_CPUCAPACITY and SMT. Also provided for > consistency with PATCH 1/4. I've also tested with/without > /proc/sys/kernel/sched_energy_aware enabled (same platform) and haven't > noticed any regression. There's a lot more to unpack, but just to confirm, Vera doesn't have an EM, right? There's no EAS with it? (To be more precise, CPPC should bail out of building an artifical EM if there's no or only one efficiency class: drivers/cpufreq/cppc_cpufreq.c: if (bitmap_weight(used_classes, 256) <= 1) { pr_debug("Efficiency classes are all equal (=%d). " "No EM registered", class); return; } This is the case, right? > [snip]