From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp153-162.sina.com.cn (smtp153-162.sina.com.cn [61.135.153.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 A8D1A3FF1 for ; Tue, 2 Dec 2025 09:47:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=61.135.153.162 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764668859; cv=none; b=jC4SLGkMhOZe5bd6/8CLOc3x71G6QVtcPshhClolFyiO1C75p6t/uxK/lxDWjmTucukY+7fA9BY+KeomAFV8705cm8KBZT5eZ18ICV3fR0L3sNdN2HcRKejAYCV+IUITFHXX5E76rpgtdhYyAW/firuBX2iM1neHu4IXhz5d4OQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764668859; c=relaxed/simple; bh=rVwm5a3fhwm59Ddf+5+iTe0g7cz8mimTUiLbSyIL+y4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ofF3G+fiWbzmNfDQgOdW1ptBS8p91SGlxIP6bJGwRt7TW96zABhAo62CyS6edjLopZv9WJiDFtY2YXNOLhDDGiByQRtRfFJr5H70We64eFVFeQqXR5/x8+Y/lfYWfbLOlA0AkpjHMhkBxedJutBxT5ekw1c0+sAHFHexDX2i0kA= 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=LO/QUP06; arc=none smtp.client-ip=61.135.153.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="LO/QUP06" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1764668850; bh=kcfX1cN4iT4GOXOukrjIaAlf0c4IPGP9aJPuI3NIPcM=; h=From:Subject:Date:Message-ID; b=LO/QUP0666SBsTkpqgWzYtkbM4VuYF7ijDorQ//GGLvuhQHh0yNt+SuI75wqaXmh3 6ENXzccyFoKp7hOAZP9qjKvHYTN20hw2seIsp/P6mfB6x7JPz6kq293ZDiTCcOtPtg VBUiRQd+IbcXdWvEQCbwVBHBhj7dflDeln6c6LFQ= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.57.85]) by sina.com (10.54.253.31) with ESMTP id 692EB51E000073DD; Tue, 2 Dec 2025 17:45:04 +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: 5139426816075 X-SMAIL-UIID: 790C77CA37024298AEBB30C2C4097306-20251202-174504-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: Tue, 2 Dec 2025 17:44:52 +0800 Message-ID: <20251202094454.9608-1-hdanton@sina.com> In-Reply-To: <20251201091308.761711-7-vincent.guittot@linaro.org> References: <20251201091308.761711-1-vincent.guittot@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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. > + > + if (sched_idle_push_task(p, rq)) > + return true; > + > return false; > } > More, in the tick path, task_tick_fair check_pushable_task fair_push_task task_on_rq_queued // this check makes no sense