[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z5fmJHcuKG4hfDbJ@slm.duckdns.org>
Date: Mon, 27 Jan 2025 10:01:40 -1000
From: Tejun Heo <tj@...nel.org>
To: Changwoo Min <changwoo@...lia.com>
Cc: void@...ifault.com, arighi@...dia.com, kernel-dev@...lia.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 03/11] sched_ext: Add an event, SELECT_CPU_FALLBACK
Hello,
On Sun, Jan 26, 2025 at 07:16:06PM +0900, Changwoo Min wrote:
...
> struct scx_event_stats {
> + /*
> + * If ops.select_cpu() returns a CPU which can't be used by the task,
> + * the core scheduler code silently picks a fallback CPU.
> + */
> + u64 SELECT_CPU_FALLBACK;
As C has one global namespace, we're gonna have to prefix these. Hopefully,
something not too long. SCX_EV_?
> @@ -3663,6 +3668,10 @@ static int select_task_rq_scx(struct task_struct *p, int prev_cpu, int wake_flag
> cpu = SCX_CALL_OP_TASK_RET(SCX_KF_ENQUEUE | SCX_KF_SELECT_CPU,
> select_cpu, p, prev_cpu, wake_flags);
> *ddsp_taskp = NULL;
> +
> + if (unlikely(!is_cpu_allowed(p, cpu)))
> + __scx_add_event(SELECT_CPU_FALLBACK, 1);
This is trying to guess what select_task_rq() is going to do and then count
that as an event, which doesn't seem great. Can't we just record the picked
CPU here into a field in p->scx and then compare that against cpu_of(rq) in
enqueue_task_scx()? That way, we can reliably count events where CPU
selection was modified by the fallback logic regardless of why or how that
happens.
Thanks.
--
tejun
Powered by blists - more mailing lists