Hello Tejun,
On Fri, Nov 10, 2023 at 04:47:38PM -1000, Tejun Heo wrote:
[..]
> +/*
> + * Omitted operations:
> + *
> + * - wakeup_preempt: NOOP as it isn't useful in the wakeup path because the task
> + * isn't tied to the CPU at that point.
> + *
> + * - migrate_task_rq: Unncessary as task to cpu mapping is transient.
> + *
> + * - task_fork/dead: We need fork/dead notifications for all tasks regardless of
> + * their current sched_class. Call them directly from sched core instead.
> + *
> + * - task_woken, switched_from: Unnecessary.
> + */
> +DEFINE_SCHED_CLASS(ext) = {
> + .enqueue_task = enqueue_task_scx,
> + .dequeue_task = dequeue_task_scx,
> + .yield_task = yield_task_scx,
> + .yield_to_task = yield_to_task_scx,
> +
> + .wakeup_preempt = wakeup_preempt_scx,
I was wondering about the comment above related to 'wakeup_preempt', could
you clarify why it is not useful (NOOP) in the sched-ext class?
wakeup_preempt() may be called via:
sched_ttwu_pending() ->
ttwu_do_activate() ->
wakeup_preempt()
at which point the enqueue of the task could have already happened via:
sched_ttwu_pending() ->
ttwu_do_activate() ->
activate_task() ->
enqueue_task()
But the comment above says "task isn't tied to the CPU" ?
Apologies in advance if I missed something as I just recently starting
looking into the sched-ext patches.
thanks!
- Joel
