Re: [RFC PATCH 01/20] sched: Add task enqueue/dequeue trace points

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `sched_enqueue_tp` tracepoint is invoked before the scheduler class has actually enqueued the task, resulting in trace consumers observing stale task state.
--

commit cd98b289fdbaccae680f140f19c0e9bd5dd972b6
Author: Nam Cao <namcao@linutronix.de>

sched: Add task enqueue/dequeue trace points

This commit adds tracepoints into the scheduler's enqueue and dequeue paths
to allow tracing task scheduling events.

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f78275192036b..8561ca324943a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
[ ... ]
> @@ -2181,6 +2183,9 @@ unsigned long get_wchan(struct task_struct *p)
>  
>  void enqueue_task(struct rq *rq, struct task_struct *p, int flags)
>  {
> +	if (trace_sched_enqueue_tp_enabled() && !(flags & ENQUEUE_DELAYED))
> +		trace_sched_enqueue_tp(p, cpu_of(rq));
> +
[Severity: Medium]
Because this tracepoint is placed at the beginning of the function, prior to
p->sched_class->enqueue_task(), will trace consumers observe stale task
state?

For example, it seems that when the tracepoint triggers here, metrics like
se.vruntime have not yet been denormalized for the new runqueue, the EEVDF
se.deadline has not been recomputed, and on_rq is still 0.

Does it make sense to move this after the class-specific enqueue operation
completes, mirroring how dequeue_task() handles this by emitting
trace_sched_dequeue_tp() after calling p->sched_class->dequeue_task()?

>  	if (!(flags & ENQUEUE_NOCLOCK))
>  		update_rq_clock(rq);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831090524.106845-1-gmonaco@redhat.com?part=1