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 683CD2DAFC8 for ; Mon, 1 Dec 2025 13:31:50 +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=1764595913; cv=none; b=AFs+EMDkmmP/Bxf8yX0FYv8lRjhtc7pxY9YXahrJlA9czC7c//KQAJb9PFMCBMNgfQ68ihfCnoO7I63A/0xNIwUA1YqvH+gF7wgc8pV4hGQ/aH8GxJxmMJlMWjIBb0juqRXK0r5+OzxPoeLzOouy03izVT6syw7NTa8f8C/n87A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764595913; c=relaxed/simple; bh=8vatzNewKFnHSfKQ6BOrHCQE0N9eoKabhxFix2TILfY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ucJFdaOUeLhXQOfxvAx1ThxzQVnylcn7mlLUTsny5V2DHPsJupW1qjy8o9VX3ACHDSLilisbh6ntWNb06Yff4w9Eaee9ZXry+TAUsZWaw8bUcafl9I3FHmyfb5QOEs1vM09t2p5AuzyKM9hytqZXAZZ+mIsTmsO9rruOD5gIiMU= 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 0EDF8153B; Mon, 1 Dec 2025 05:31:41 -0800 (PST) Received: from [10.1.29.49] (e127648.arm.com [10.1.29.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 512913F73B; Mon, 1 Dec 2025 05:31:45 -0800 (PST) Message-ID: <18aa730a-01c5-48d8-9f08-44f4dfca4808@arm.com> Date: Mon, 1 Dec 2025 13:31:43 +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/6 v7] sched/fair: Add push task mecansim and hadle more EAS cases To: 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 Cc: qyousef@layalina.io, hongyan.xia2@arm.com, luis.machado@arm.com References: <20251201091308.761711-1-vincent.guittot@linaro.org> Content-Language: en-US From: Christian Loehle In-Reply-To: <20251201091308.761711-1-vincent.guittot@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/1/25 09:13, Vincent Guittot wrote: > This is a subset of [1] (sched/fair: Rework EAS to handle more cases) > > [1] https://lore.kernel.org/all/20250314163614.1356125-1-vincent.guittot@linaro.org/ > > The current Energy Aware Scheduler has some known limitations which have > became more and more visible with features like uclamp as an example. This > serie tries to fix some of those issues: > - tasks stacked on the same CPU of a PD > - tasks stuck on the wrong CPU. > > Patch 1 fixes the case where a CPU is wrongly classified as overloaded > whereas it is capped to a lower compute capacity. This wrong classification > can prevent periodic load balancer to select a group_misfit_task CPU > because group_overloaded has higher priority. > > Patch 2 removes the need of testing uclamp_min in cpu_overutilized to > trigger the active migration of a task on another CPU. > > Patch 3 prepares select_task_rq_fair() to be called without TTWU, Fork or > Exec flags when we just want to look for a possible better CPU. > > Patch 4 adds push call back mecanism to fair scheduler but doesn't enable > it. > > Patch 5 enable has_idle_core for !SMP system to track if there may be an > idle CPU in the LLC. > > Patch 6 adds some conditions to enable pushing runnable tasks for EAS: > - when a task is stuck on a CPU and the system is not overutilized. > - if there is a possible idle CPU when the system is overutilized. > > More tests results will come later as I wanted to send the pachtset before > LPC. > > Tbench on dragonboard rb5 > schedutil and EAS enabled > > # process tip +patchset > 1 29.1(+/-4.1%) 124.7(+/-12.3%) +329% > 2 60.0(+/-0.9%) 216.1(+/- 7.9%) +260% > 4 255.8(+/-1.9%) 421.4(+/- 2.0%) +65% > 8 1317.3(+/-4.6%) 1396.1(+/- 3.0%) +6% > 16 958.2(+/-4.6%) 979.6(+/- 2.0%) +2% Just so I understand, there's no uclamp in the workload here? Could you expand on the workload a little, what were the parameters/settings? So the significant increase is really only for nr_proc < nr_cpus, with the observed throughput increase it'll probably be something like "always running on little CPUs" vs "always running on big CPUs", is that what's happening? Also shouldn't tbench still have plenty of wakeup events? It issues plenty of TCP anyway. > > Hackbench didn't show any difference > > > Vincent Guittot (6): > sched/fair: Filter false overloaded_group case for EAS > sched/fair: Update overutilized detection > sched/fair: Prepare select_task_rq_fair() to be called for new cases > sched/fair: Add push task mechanism for fair > sched/fair: Enable idle core tracking for !SMT > sched/fair: Add EAS and idle cpu push trigger > > kernel/sched/fair.c | 350 +++++++++++++++++++++++++++++++++++----- > kernel/sched/sched.h | 46 ++++-- > kernel/sched/topology.c | 3 + > 3 files changed, 346 insertions(+), 53 deletions(-) >