From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-162.sinamail.sina.com.cn (mail3-162.sinamail.sina.com.cn [202.108.3.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5A6EF2D73B0 for ; Wed, 3 Dec 2025 09:06:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.162 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764752785; cv=none; b=PHudSRZUgUnDYMbWDI1ksv/cp+G4AuX1CQ81IcNQxCAwh1GN6Jj/n2/6GDvVdxx7lBY1vjlPB/0wk1zXTfRLiGULy0YlBqC4d6WaeZrBC6w1TAnm5L3HLDyAg6eVNtWdt3DZwk7L8XTyoAEb97iFctMP6ogYNLWbMMydnfrnZOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764752785; c=relaxed/simple; bh=qmTbBSQhisP8oEtPHfKG7nJhzNSilPeOOUgUoklWlt8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CxrrKgnamXgHq63AgU3/iipbb9Wr80Qj1U7JUNj8JK4OBa2fxsWom8ww3km+zDFH3Du0Ksvj7AxU9tOZvtnE7N1Hi9dTl09MXzN6usfxiFx6NOdKs/Pfm//uA2lHEv38hdSwwQ4hTJF5o2UmAETN/ahmlqltUCfgA0H38n7C0C0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b=PXHYMsSu; arc=none smtp.client-ip=202.108.3.162 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b="PXHYMsSu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1764752780; bh=AbwMaSRoOEiYPnHXkwWqWCm55UOpaw+HF9aq0YxRDFI=; h=From:Subject:Date:Message-ID; b=PXHYMsSuRVDOIOJb7okMH7zeQDUzU4fHjc+oqvJe/6miMmOPnIbW9+u5xV/z2+Vhl EXPPszYVmZMBU7G+hA5zgobAD7UJya6s69oh/7VBIvXkQDczwX98YNM4HfdfOAMXf3 tI+Jqr7DLC8LNoQvlwF0i5RGBjO1on0bbKUOlRWU= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.57.85]) by sina.com (10.54.253.34) with ESMTP id 692FFC42000050C3; Wed, 3 Dec 2025 17:00:52 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 7090776291739 X-SMAIL-UIID: E6173B34C7764CAB91E2EE93E0E9971C-20251203-170052-1 From: Hillf Danton To: Vincent Guittot Cc: peterz@infradead.org, linux-kernel@vger.kernel.org, pierre.gondois@arm.com, kprateek.nayak@amd.com, qyousef@layalina.io, christian.loehle@arm.com, luis.machado@arm.com Subject: Re: [RFC PATCH 6/6 v7] sched/fair: Add EAS and idle cpu push trigger Date: Wed, 3 Dec 2025 17:00:40 +0800 Message-ID: <20251203090042.1804-1-hdanton@sina.com> In-Reply-To: References: <20251201091308.761711-1-vincent.guittot@linaro.org> <20251201091308.761711-7-vincent.guittot@linaro.org> <20251202094454.9608-1-hdanton@sina.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-Transfer-Encoding: 8bit On Tue, 2 Dec 2025 14:01:39 +0100 Vincent Guittot wrote: >On Tue, 2 Dec 2025 at 10:45, Hillf Danton wrote: >> On Mon, 1 Dec 2025 10:13:08 +0100 Vincent Guittot wrote: >> > EAS is based on wakeup events to efficiently place tasks on the system, but >> > there are cases where a task doesn't have wakeup events anymore or at a far >> > too low pace. For such cases, we check if it's worht pushing hte task on >> > another CPUs instead of putting it back in the enqueued list. >> > >> > Wake up events remain the main way to migrate tasks but we now detect >> > situation where a task is stuck on a CPU by checking that its utilization >> > is larger than the max available compute capacity (max cpu capacity or >> > uclamp max setting) >> > >> > When the system becomes overutilized and some CPUs are idle, we try to >> > push tasks instead of waiting periodic load balance. >> > >> > Signed-off-by: Vincent Guittot >> > --- >> > kernel/sched/fair.c | 65 +++++++++++++++++++++++++++++++++++++++++ >> > kernel/sched/topology.c | 3 ++ >> > 2 files changed, 68 insertions(+) >> > >> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> > index 9af8d0a61856..e9e1d0c05805 100644 >> > --- a/kernel/sched/fair.c >> > +++ b/kernel/sched/fair.c >> > @@ -6990,6 +6990,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags) >> > } >> > >> > static void fair_remove_pushable_task(struct rq *rq, struct task_struct *p); >> > + >> > /* >> > * Basically dequeue_task_fair(), except it can deal with dequeue_entity() >> > * failing half-way through and resume the dequeue later. >> > @@ -8499,8 +8500,72 @@ static inline bool sched_push_task_enabled(void) >> > return static_branch_unlikely(&sched_push_task); >> > } >> > >> > +static inline bool task_stuck_on_cpu(struct task_struct *p, int cpu) >> > +{ >> > + unsigned long max_capa, util; >> > + >> > + max_capa = min(get_actual_cpu_capacity(cpu), >> > + uclamp_eff_value(p, UCLAMP_MAX)); >> > + util = max(task_util_est(p), task_runnable(p)); >> > + >> > + /* >> > + * Return true only if the task might not sleep/wakeup because of a low >> > + * compute capacity. Tasks, which wake up regularly, will be handled by >> > + * feec(). >> > + */ >> > + return (util > max_capa); >> > +} >> > + >> > +static inline bool sched_energy_push_task(struct task_struct *p, struct rq *rq) >> > +{ >> > + if (!sched_energy_enabled()) >> > + return false; >> > + >> > + if (is_rd_overutilized(rq->rd)) >> > + return false; >> > + >> > + if (task_stuck_on_cpu(p, cpu_of(rq))) >> > + return true; >> > + >> > + if (!task_fits_cpu(p, cpu_of(rq))) >> > + return true; >> > + >> > + return false; >> > +} >> > + >> > +static inline bool sched_idle_push_task(struct task_struct *p, struct rq *rq) >> > +{ >> > + if (rq->nr_running == 1) >> > + return false; >> > + >> > + if (!is_rd_overutilized(rq->rd)) >> > + return false; >> > + >> > + /* If there are idle cpus in the llc then try to push the task on it */ >> > + if (test_idle_cores(cpu_of(rq))) >> > + return true; >> > + >> > + return false; >> > +} >> > + >> > + >> > static bool fair_push_task(struct rq *rq, struct task_struct *p) >> > { >> > + if (!task_on_rq_queued(p)) >> > + return false; >> >> Task is queued on rq. >> > + >> > + if (p->se.sched_delayed) >> > + return false; >> > + >> > + if (p->nr_cpus_allowed == 1) >> > + return false; >> > + >> > + if (sched_energy_push_task(p, rq)) >> > + return true; >> >> If task is stuck on CPU, it could not be on rq. Weird. > > May be it comes from my description and I should use task_stuck_on_rq > By stuck, I mean that the task doesn't have any opportunity to migrate > on another cpu/rq and stay "forever" (at least until next sleep) on > this cpu/rq because load balancing is disabled/bypassed w/ EAS > Here Stuck does not mean blocked/sleeping > Given task queued on rq, I find the correct phrase, stack, in the cover letter instead of stuck, and the long-standing stacking tasks mean load balancer fails to cure that stack. 1/7 fixes that failure, no?