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 0C1293E8C61 for ; Wed, 18 Mar 2026 15:43:30 +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=1773848614; cv=none; b=rPe49QhMX4zpM4+TuMjtXAXK+mXRHyy6PQQ99DwVXasuogVVCpFvC7MczLSdLN7Os1be884SESe3wLxIxRP+0MkLcnAZHhrfN7pfdRYRdxtwBsoherHpDEvB9a4D45LRSOeKyEjETcjQyYr1+l/TMktQ5uz6ygcEQZX2jY+gjvw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773848614; c=relaxed/simple; bh=kUw/DRf+gn5+n9iJnmO3arezOnwyy5Pe06yd5ubulN0=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=OUplafEBAK3c59qD1Jy2iZF5VQvKa0rp/Gr8bozQ+6CpDx8OVlcn7bnOYXT+qNvK7+tqC9Kx766Odsc+5u17+IRPSgBeWjEYowu3jqYa99/79C9Wfcdt2oJBLVny4Y8wD0zLYM5NmBQ311J+xw0kF27N0r1bb2vZrj9GRTh1hU4= 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; 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 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 39A7B1C2B; Wed, 18 Mar 2026 08:43:24 -0700 (PDT) Received: from [10.57.17.91] (unknown [10.57.17.91]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 11A1C3F73B; Wed, 18 Mar 2026 08:43:27 -0700 (PDT) Message-ID: <4830a5aa-0682-4501-af92-8a2e7858b1d3@arm.com> Date: Wed, 18 Mar 2026 15:43:26 +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 From: Christian Loehle Subject: Re: [PATCH] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection To: Andrea Righi , Vincent Guittot Cc: Ingo Molnar , Peter Zijlstra , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Joel Fernandes , linux-kernel@vger.kernel.org References: <20260318092214.130908-1-arighi@nvidia.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/18/26 10:31, Andrea Righi wrote: > Hi Vincent, > > On Wed, Mar 18, 2026 at 10:41:15AM +0100, Vincent Guittot wrote: >> On Wed, 18 Mar 2026 at 10:22, Andrea Righi wrote: >>> >>> On systems with asymmetric CPU capacity (e.g., ACPI/CPPC reporting >>> different per-core frequencies), the wakeup path uses >>> select_idle_capacity() and prioritizes idle CPUs with higher capacity >>> for better task placement. However, when those CPUs belong to SMT cores, >> >> Interesting, which kind of system has both SMT and SD_ASYM_CPUCAPACITY >> ? I thought both were never set simultaneously and SD_ASYM_PACKING was >> used for system involving SMT like x86 > > It's an NVIDIA platform (not publicly available yet), where the firmware > exposes different CPU capacities and has SMT enabled, so both > SD_ASYM_CPUCAPACITY and SMT are present. I'm not sure whether the final > firmware release will keep this exact configuration (there's a good chance > it will), so I'm targeting it to be prepared. Andrea, that makes me think, I've played with a nvidia grace available to me recently, which sets slightly different CPPC highest_perf values (~2%) which automatically will set SD_ASYM_CPUCAPACITY and run the entire capacity-aware scheduling machinery for really almost negligible capacity differences, where it's questionable how sensible that is. I have an arm64 + CPPC implementation for asym-packing for this machine, maybe we can reuse that for here too? (Given that really capacity and SMT are contradicting, e.g. a physical core with 1024 capacity but 4 threads may give you a lot lower observed CPU capacity than a 512 nosmt core per (logical) CPU depending on how much the sibling threads are utilized.) > [snip]