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

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Oct 02, 2026 at 01:55:48PM +0200, Gabriele Monaco wrote:
> 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.

So the .c files are no longer an artifact? That seems unfortunate. I
thought the .dot file was fully descriptive and the .c file was fully
generated by dot2c.

If we cannot fully express the automaton in .dot, we should look at
extending the 'format' and teach dot2c new tricks.

> 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.

I'm not sure I'm following. Will you be in Prague next week?

> > 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.

So personally I have 0 interest or use for html. Mail is text, code is
text, we use a text editor (neovim is my current poison of choice).
Nowhere is there html. So then having to look at rst is just crap. rst
gets in the way of actually reading the thing. All down-sides, no
up-sides.