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

Il 2 ottobre 2026 19:18:42 UTC, Peter Zijlstra [off-list ref] ha scritto:

On Fri, Oct 02, 2026 at 01:55:48PM +0200, Gabriele Monaco wrote:

quoted

On Fri, 2026-10-02 at 12:29 +0200, Peter Zijlstra wrote:

quoted

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.

quoted

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.

The linking between events and tracepoint has always been manual, but yeah, it would be nice to describe the whole thing in the specification.

Though that would require quite a bit of work, deadline and LTL monitors have some more complicated mapping.

quoted

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?

Yes I'll be there. We can definitely discuss this better.

Thanks,
Gabriele

quoted

quoted

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.