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 7DC602DC352 for ; Wed, 18 Feb 2026 16:13:01 +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=1771431183; cv=none; b=kUNlA+V6TdYSP4rQoSVkBP991wZUEnYWHjVHsPuZGHK9+/XXf1KIQyO/Pz3xadDeU3FE2ZYoPI6iNzacu0Z4KvWt3PKHJv7/GE7JnAwaLXU3zqw00rQuyQ99g9Zqx76wi0BOCtE2V37GMe6w4oUhViDdvuhI5DKkZ70BIiV/jKI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771431183; c=relaxed/simple; bh=8n7LFF1Kp2+RaczANclvVrGzBMGB89VSDvhmhpaRvu0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=as/IweXRvCQl2fubLJobUyg7sJtc3/NLVKWfPLhsyRXhj0LIfUIkRWAzUE+r59sYwGVmUf51SauQD9tM+2AEilb+cWicsKyVuZoTD1M3cDoHuYQFrEPhDP14fhi8R+FrZurCqM8qxC3yWVxzbnsMkHsHpJ6Xt0oYNOQq0k26p3w= 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 80670339; Wed, 18 Feb 2026 08:12:54 -0800 (PST) Received: from [10.1.31.60] (e127648.arm.com [10.1.31.60]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E1A933F62B; Wed, 18 Feb 2026 08:12:57 -0800 (PST) Message-ID: <140e7fa8-c965-4e29-9c34-2f37fc9c643e@arm.com> Date: Wed, 18 Feb 2026 16:12:56 +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 v9] sched/fair: Filter false overloaded_group case for EAS To: Qais Yousef Cc: Vincent Guittot , mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, pierre.gondois@arm.com, kprateek.nayak@amd.com, hongyan.xia2@arm.com, luis.machado@arm.com References: <20260206095454.1520619-1-vincent.guittot@linaro.org> <20260211014839.urv4kyi2lmnvl3su@airbuntu> <80d26683-5560-470d-8713-0ce64743f9dd@arm.com> <20260217010312.dm6r4zata5dazvfx@airbuntu> Content-Language: en-US From: Christian Loehle In-Reply-To: <20260217010312.dm6r4zata5dazvfx@airbuntu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/17/26 01:03, Qais Yousef wrote: > On 02/12/26 09:55, Christian Loehle wrote: >> On 2/11/26 01:48, Qais Yousef wrote: >>> On 02/06/26 10:54, Vincent Guittot wrote: >>>> With EAS, a group should be set overloaded if at least 1 CPU in the group >>>> is overutilized but it can happen that a CPU is fully utilized by tasks >>>> because of clamping the compute capacity of the CPU. In such case, the CPU >>>> is not overutilized and as a result should not be set overloaded as well. >>>> >>>> group_overloaded being a higher priority than group_misfit, such group can >>>> be selected as the busiest group instead of a group with a mistfit task >>>> and prevents load_balance to select the CPU with the misfit task to pull >>>> the latter on a fitting CPU. >>>> >>>> Signed-off-by: Vincent Guittot >>>> Tested-by: Pierre Gondois >>>> --- >>>> >>>> This patch was part of a larger patchset [1] but makes sense on its own and has >>>> not changed since v2 >>>> >>>> [1] https://lore.kernel.org/all/20251202181242.1536213-1-vincent.guittot@linaro.org/ >>> >>> I don't mind this. But I think with the original series misfit will be handled >>> better with push lb, and if it is made to handle overloaded case (which my >>> initial testing shows it is easily doable and I can't see clear bad impact >>> yet), I think we can retire overutilized altogether. >>> >> >> The EAS wakeup path (and therefore the push lb for that matter) is costly and workloads >> are sensitive to it, it's trivial to see with hackbench. Overutilized prevents that. > > What workloads? I have been testing this and all I am seeing are great results > so far. > > Hackbench is a super synthetic test that doesn't represent any real workload. > It purely measures context switch overhead. I think I said this before, but > I'll repeat it again. For most modern systems and workloads we really need to > spend more time to make sure we do the correct task placement decision as the > cost of a wrong fast decision is worse than a slow correct one. And this is not > something special about mobile systems. Servers and others do care. For those > who really don't want any additional overhead they can just disable the static > key. There's quite a few systems and workloads, especially in servers / datacenters where the "fast cheap" placement is better... But I guess that's going a bit off-topic now. > > FWIW I tried schbench, which is more realistic since it does something that > represents a web server, and it measures throughput and latencies and I got 10% > better throughput, 27% better P99 and 49% better max latencies. And yes, OU is > completely disabled when I ran this test. > > But disclaimer again, I backported earlier (modified) version of the patch and > running on non-mainline kernel with OOT changes applied that I think helps to > demonstrate the benefit even better. So I'm assuming this was with the old series that still changed feec() placement trying a 'latency-aware' placement, otherwise the improvements you state don't make sense to me. > > Vincent, I am trying to stress the importance of the work and its great > potential. I am not expecting the initial merge to handle everything yet ;-) > >> Arguments about PELT inaccuracies during periods of unmet compute demand (and therefore >> entirely bogus EAS computation results) aside, I don't see how we a push lb could retire >> OU? If anything you're paying twice the price then for these scenarios? > > I am not seeing any price to be paid. Geekbench scores are within run-to-run > variation. Hackbench isn't the only one here, I can make an overview too. There's definitely a measurable speedometer3.1 score regression with "never-OU", too. Again though, if you tested this extensively and think the improvements outweigh, please do share the setup and results.