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 493F8314D2F for ; Mon, 1 Dec 2025 13:57:48 +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=1764597471; cv=none; b=b0NM9Y/6u/TmcqT8y/8477t5NfDhfWv6pNsNYVlkcZhoLqi4cHNsIPvL1bgBMZDr/7HzGhl1I7R5ACg8NuRdWINIQKQZ2WIjyNgFzzWirvop1ndet4DRkryYjNPdu9FOT9pfZJasIuk5wDYfH1ot9pWliwZetVElRE4BTb5rjs0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764597471; c=relaxed/simple; bh=2CKMqiMhOf8lOY75GUUnXGU5VQJXpcHGv5zGlc2UJZ4=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=tbnWohLOprC7iYGq9Z7G5CEiblnKbvZFKlTiEGYBkFrUTrpenof835AkNJDUuVKG2M9+HMi7tiZtGvuolxVBd47YGst54w2FWKtBPw5HICUB987JZwm6LjADIJ5+bcBiXZFQrgr54sWWdoR1SqkTN2urJLsWF+UlPknUI6+DsSI= 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 2667A1595; Mon, 1 Dec 2025 05:57: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 62A213F73B; Mon, 1 Dec 2025 05:57:45 -0800 (PST) Message-ID: Date: Mon, 1 Dec 2025 13:57: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 From: Christian Loehle 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> <18aa730a-01c5-48d8-9f08-44f4dfca4808@arm.com> Content-Language: en-US In-Reply-To: <18aa730a-01c5-48d8-9f08-44f4dfca4808@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Nit in the title: mechanism, handle On 12/1/25 13:31, Christian Loehle wrote: > 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. ... or if not why does OU not trigger on tip? > >> >> 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(-) >> I can't apply this on yesterday's released 6.18 and not on tip/sched-core, what's this based on? Can I get a branch or a 6.18 rebase?