From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 297511DB375 for ; Tue, 17 Feb 2026 01:03:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771290197; cv=none; b=RXAF3B3OQAsWSElD0FcFZz4HD7Ii/nofViKXOzCzzALI6rGQECVts61FYwXQ2uVxCVuOaY6ZRQag0qDwUEsJW58Igs4rbEAmH3Twgb0pT66KircVd7RnX7l9y1BFWNUJYtIzsPxVO0zAG1f6AxHbHN5vHEDxkxXXGL0QtV/H71A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771290197; c=relaxed/simple; bh=elyViLvWpiwZ4zCi4QzyzU1K0Ci2Nxp5T83nIrlgH9Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MoZjuao7KGcXBHa8Fevyl8vHb59qvf0wnnSKPTe81GqKKdT3DzGD0QXYvibj54O7Hry1DWESw7RFNZLk+U70znYFee/i1J5lJTbZ2tjC4Y5rDSpgkzGBFT/6CnKHJN9cSMAjAZo1DUQa63+6zZi33OvPntG6uo+a1Fl5gsM5uZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io; spf=pass smtp.mailfrom=layalina.io; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b=1/0wReF4; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=layalina.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b="1/0wReF4" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4806f3fc50bso44015025e9.0 for ; Mon, 16 Feb 2026 17:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1771290194; x=1771894994; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=H0S1BJKkktzNmr1PNbXMQBzsoDwQtefbDDbyWZuETyQ=; b=1/0wReF4O6x1BV77gvIzJ6ZM8jQikfexeXZ0QHMf5VBucBj2e7v43YrTQ3fC95YCqz QKCJJQTiHCBpj34bohrPy9khG5Y48QjMEXVIxsbRAU4j29rPIElVZnHzPA4GhTAO434H FuesER/UFd64Oi5XgQM7Q79FOTuVP/6qvTStcWgD27qHoOqJMiuXLhQj0vkluMZsFdCP qzD/28LMF2l4suQCybsOar6RZ2pTBWuKyVhKCcnf/USug/4E742Y2IbDR1xX2g1sl6la MQ54TMZWGAEujspm0/xzs26TkhlfDMMbXf20dAvnyFpq9KJvPWfBi9YEzdLSUiYmzeR/ 6bmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771290194; x=1771894994; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H0S1BJKkktzNmr1PNbXMQBzsoDwQtefbDDbyWZuETyQ=; b=bxKchXB51xfNwjFb6rAXnKBhOCiaEuzPS7qfc47nrkKl5nc3J9ymxgADiH3PT4iV8/ t9XAPdQvyuHm/3bmPllk8mCtYUOM+yV5L9LcNgNDs3Sf+mue/x0Y8VFQXF7hrRL4JvSj n6rdL3NWLRgao6NunRbMLEJz4Cd4mkUGlDVWmKcL0GEa2pUZFz29S5Lo8MWsSBzezQG/ kSXEQbr41RPOrMdEgWM5+lB645mNjkZVebJCUYXXp1EZ0T3Nhgzz2dk7itk7A1EG6Q8M 0ZKe8a5M7JD/y3RwdxacBKVj4Pf9yb+k7TXb8KABamTM4UOR9clfZaSzE+jTa1bHaLJh l38A== X-Forwarded-Encrypted: i=1; AJvYcCXBg3zqJGFbvYZ2kjLLpVJH9FjfrrUxopas2hkZWME4zALHQaAbF+nEsjXnnqCHQI5dBiRMwzk8ZIlFAco=@vger.kernel.org X-Gm-Message-State: AOJu0YzhkorhSANmhV8/FMJjOCZGaQBoWVXR/w2SBtvH+FeXVAvnauiQ 59XDBQTRdrjFEr44eOF0kkanhF8tc4zZVRkmU//88jA1vvCDoN0jHtTGaZh/Y43QjGo= X-Gm-Gg: AZuq6aJ1FDQixg/EFAqhQSP1h+3ETkjMr4xMg2oApDjjRbmn24/p5EM90bGOXLEZFKJ cqkRv0/O5qwSjJfpe1SFScUyLGDNoxDXOi7/WYIW8PfUkVJujxWuSAxD9KeEHB6OAuW+Su3ddHC iQz4W/iuaedf1ezSVcokdaaHRfipq5c8Ql6RT7XEAp2+GCiDGuazYvvS1x2N5w5wL04JFNfls+X EFRzntMA6mFwQh/Ws9+ZzBq0CRo6ThmhjuxXBwyOg47D9RqpMkQaiaujWBRdPO8s2tZvt7KUlny jEMHuf2lxowZq47ZDsHvPUl9H4om1rDLP1tsiT0uQFtzGWx/N5VrLNk8TvOxikea22Ajh3cWnNx XQTR1tpqgmhNkPvEWxBIGGErvj1ET9XU7VKtL5M7jo+k1C5lWYSy+OlgDDpNqogA5iHeVkA4GzK 89xrFyBew6CpBqQRyIx5liH+39mXC5egT42ZYBWaJGpQN8rvIdNhevAn6AurfV0htWLMNfNLBD9 tY= X-Received: by 2002:a05:600c:468b:b0:47e:e20e:bbb2 with SMTP id 5b1f17b1804b1-48379b93583mr149867395e9.7.1771290193981; Mon, 16 Feb 2026 17:03:13 -0800 (PST) Received: from airbuntu (host109-153-232-30.range109-153.btcentralplus.com. [109.153.232.30]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4835d92267bsm707077245e9.0.2026.02.16.17.03.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 17:03:13 -0800 (PST) Date: Tue, 17 Feb 2026 01:03:12 +0000 From: Qais Yousef To: Christian Loehle 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 Subject: Re: [PATCH v9] sched/fair: Filter false overloaded_group case for EAS Message-ID: <20260217010312.dm6r4zata5dazvfx@airbuntu> References: <20260206095454.1520619-1-vincent.guittot@linaro.org> <20260211014839.urv4kyi2lmnvl3su@airbuntu> <80d26683-5560-470d-8713-0ce64743f9dd@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <80d26683-5560-470d-8713-0ce64743f9dd@arm.com> 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. 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. 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.