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 157AE3A8FF0 for ; Wed, 4 Feb 2026 10:10:37 +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=1770199838; cv=none; b=maMhEuRa1wC2x6EhxOsKaAva7r1Mh/BmphHOjyMsAGZvzuHPLyDvL/kYGe4rwRZEESV663jvsRkUowZ3W0+xB/Ut1m2bLC8OmB1jF+azdVihOjcIZKkwOibTOofnZjAXD+wirH9+ylknyNQ4AX/+YjF+MyPYFFYNVcL1nzYyF0I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770199838; c=relaxed/simple; bh=tzCJeUfBvwdF9zZf56VecgHy2KulvEm6nAUt3l3gl3U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=c2AlO7f+e7VIQwuP0cTakruPhC/rUOmJF6dkYJBzlQGJRHoZMtMKI2LQuwLMKFc9eeEktAWZ0+H+yYN7ya07NpNSleLE/DUTt9LlB55U3C2e+QRsqEXf0WQQlI2joV8TM2qdZOunu0sZkiVG0bziCuan/D/JrAcnsAzF8y4glIQ= 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 1CC6A339; Wed, 4 Feb 2026 02:10:31 -0800 (PST) Received: from [10.57.68.168] (unknown [10.57.68.168]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C1AA33F632; Wed, 4 Feb 2026 02:10:35 -0800 (PST) Message-ID: Date: Wed, 4 Feb 2026 10:10:33 +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: [PATCHv2] sched/fair: Skip SCHED_IDLE rq for SCHED_IDLE task To: K Prateek Nayak , linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, vincent.guittot@linaro.org Cc: juri.lelli@redhat.com, dietmar.eggemann@arm.com, pierre.gondois@arm.com References: <20260203184939.2138022-1-christian.loehle@arm.com> <257cb7f6-2261-4f04-8a2a-23d6f4adb06c@amd.com> Content-Language: en-US From: Christian Loehle In-Reply-To: <257cb7f6-2261-4f04-8a2a-23d6f4adb06c@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2/4/26 07:48, K Prateek Nayak wrote: > Hello Chris, > > On 2/4/2026 12:19 AM, Christian Loehle wrote: >> CPUs whose rq only have SCHED_IDLE tasks running are considered to be >> equivalent to truly idle CPUs during wakeup path. For fork and exec >> SCHED_IDLE is even preferred. >> This is based on the assumption that the SCHED_IDLE CPU is not in an >> idle state and might be in a higher P-state, allowing the task/wakee >> to run immediately without sharing the rq. >> >> However this assumption doesn't hold if the wakee has SCHED_IDLE policy >> itself, as it will share the rq with existing SCHED_IDLE tasks. In this >> case, we are better off continuing to look for a truly idle CPU. >> >> On a Intel Xeon 2-socket with 64 logical cores in total this yields >> for kernel compilation using SCHED_IDLE: >> >> +---------+----------------------+----------------------+--------+ >> | workers | mainline (seconds) | patch (seconds) | delta% | >> +=========+======================+======================+========+ >> | 1 | 4384.728 ± 21.085 | 3843.250 ± 16.235 | -12.35 | >> | 2 | 2242.513 ± 2.099 | 1971.696 ± 2.842 | -12.08 | >> | 4 | 1199.324 ± 1.823 | 1033.744 ± 1.803 | -13.81 | >> | 8 | 649.083 ± 1.959 | 559.123 ± 4.301 | -13.86 | >> | 16 | 370.425 ± 0.915 | 325.906 ± 4.623 | -12.02 | >> | 32 | 234.651 ± 2.255 | 217.266 ± 0.253 | -7.41 | >> | 64 | 202.286 ± 1.452 | 197.977 ± 2.275 | -2.13 | >> | 128 | 217.092 ± 1.687 | 212.164 ± 1.138 | -2.27 | >> +---------+----------------------+----------------------+--------+ > > I couldn't spot much difference for kernel compilation on my > 3rd Generation EPYC system likely due to smaller LLC size. For > sched-messaging, I found the following interesting trend when > running with SCHED_IDLE: > > (Normalized runtime [Var%]; %diff - higher the better) > > tip/sched:core +patch (%diff) > > 1-group 1.00 [5.00%] 0.88 [10.78%] 11.80% > 2-group 1.00 [5.15%] 0.93 [26.06%] 6.99% > 4-group 1.00 [5.48%] 0.89 [11.03%] 11.13% > 8-group 1.00 [6.62%] 1.21 [12.37%] -21.30% > 16-group 1.00 [9.46%] 1.28 [ 9.42%] -27.59% > > > There is a good improvement for lower utilization. Once the > system is trending towards overutilized but SIS_UTIL cut-off > is still non-zero, we search a little bit longer for a fully > idle CPU when the probability for finding one is actually > low. > > I suppose that scenario is rare where we only have SCHED_IDLE > tasks that care about throughput on a busy system to > actually notice this but it was worth pointing out. If we're unlikely to find a good candidate then doing anything on wakeup is kind of a waste of time, especially for sched messaging. So I guess without $PATCH it will basically always bail out when looking at the first few CPUs because it sees SCHED_IDLE sched messaging :) > > Feel free to include: > > Tested-by: K Prateek Nayak Thanks for testing!