Visualize the fiber currently schedule on a thread

[Dragnalith]

When using a lot of fibers you get a lot of fiber swimlane displayed at the same time and it become hard to have a global understanding of when fiber are scheduled compared to each other.

I wish to be able to see which fiber is scheduled when on a particular thread swimlane (especially to see sampled data associated with the corresponding fiber)

Ideally I would imagine something similar to context switch line on top of thread swimlane with the name of the current fiber and name of job it runs.

But in the meantime, is it possible to emulate this feature by instrumenting my app with a markup to make the name of the job appear in the thread swimlane "somehow" ?

[wolfpld]

Can you provide more details (ideally an illustration) of what you would want to see here?

[Dragnalith]

@wolfpld

At least what I would like to see is the fiber name and the current job name currently running on the thread (a fiber can be reused to run different job). When I click on the fiber name/job name it would jump to the fiber swimlane.

But ideally I would not need a swimlane per fiber, I would prefer having the fiber markup zone directly on the thread swimlane:

[wolfpld]

At least what I would like to see is the fiber name and the current job name currently running on the thread (a fiber can be reused to run different job).

You can achieve this by adding a zone scope around the fiber enter/leave markup.

But ideally I would not need a swimlane per fiber, I would prefer having the fiber markup zone directly on the thread swimlane:

I fail to see how this would be useful. A momentary insight a bunch of random stacks next to each other gives me no information at all.

[Dragnalith]

@wolfpld

You can achieve this by adding a zone scope around the fiber enter/leave markup.

I do not see how it would work. In my implementation the thread don't know the job, it's the fiber main func which loop on the job queue. The fiber context switch back to the thread when waiting for a blocking operation (like IO). Several job could have been scheduled between entering a fiber and context switch back to the thread. And when context switch back to the thread your fiber is in the middle of execution of a job.

Also a zone don't bring the click shortcut to jump to the fiber swimlane from the thread swimlane.

I fail to see how this would be useful. A momentary insight a bunch of random stacks next to each other gives me no information at all.

I would like to see how jobs are scheduled compared with each other, and see what a particular job is doing at a particular moment without scrolling vertically back on forth between fiber swimlane.

Seeing fiber spread on different swimlane does not bring me much more information.

Also when looking at the sampled callstack view of a thread scheduling fibers it's hard to understand what is going on without seeing the fiber context switch.

[wolfpld]

Ok, thanks.

[Silveryard]

I would say both forms of visualization are valid.

One swimlane per fiber is a great way to see the lifetime of a fiber, the call stacks and when/how long they executed code vs yielded.

Seeing fibers as part of the thread swimlanes gives insight into multithreading. E.g. there might be one worker thread per core executing fibers and you want to see how well your fibers are split accross those worker threads. Yes you can kind of get that information by looking at the amount of fibers in the "running" state at a given time but this is very clunky. And you only get the information "how many" are running at the same time and not "on which threads". Which might be important in big/little configurations or worker threads for different job priorities.

Also while separate swimlanes for fibers are great for longer running fibers they are not so much for short fibers. If I spawn many very small fibers for frustum culling I'd rather see them in the thread swimlane instead of cluttering up my profiler window with one swimlane per fiber.