Re: [PATCH v2 01/15] sched: Add task enqueue/dequeue trace points

[Gabriele Monaco]

On Fri, 2026-10-02 at 12:29 +0200, Peter Zijlstra wrote:
> So mostly I flat out out ignore partial series. It means I have to go
> dig around to figure out the whole picture, and anything that requires
> extra effort goes on the 'later' pile, and you know where that lives.

Alright, I guess I'm going to have to fix my to_cmd script.

> Now, as to 3,4; I'm confused. If I search 'enqueue' I see there is a
> tracepoint attach thingy in the .c file, but I don't see the
> corresponding bits in the .dot file. And per my understanding the .c
> thing is an artifact of the .dot file.

Yes but only partially. There isn't always a 1-1 mapping with model events and
tracepoints.

Throttle uses handle_sched_enqueue() for one case of dl_defer_arm, representing
a fair task running not boosted, in the enqueue case, because it was running
with another scheduler.
Boost uses handle_sched_dequeue() in a similar fashion to describe fair tasks
that stop running on the fair runqueue (but may continue on another runqueue).

In both cases I'm reusing an event that can be triggered from other tracepoints
too, ideally to keep the model simpler.

Then it uses handle_sched_enqueue() for dl_server_resume[_throttled]. They are
both plain enqueues, in fact, so I could rename them to show what they are.

> Also, IMO it would be *much* preferred if the .rst file would not exist.
> Just have the graph-easy and the description as a comment in the .dot
> file. Then you have the whole thing in one *readable* place.

Well, you make a fair point, I like to have it appear in the html docs, but
obviously no one is going to build the docs to review a patch.
I may look into ways to get both birds with a stone.

Thanks,
Gabriele