Hi Phil, Thank you very much for your feedback! It is really valuable for us.I have one idea what may cause this misbehavior. The sched_events plugin deals not only with the sched_switch events but also with the different wakeup events and if you don't have any wakeup event enabled when you recorded the trace data (no wakeup event in your trace.dat file), the plugin will fail to initialize. This is not how it should work and fixing this issue is in my to-do list since quite some time.
Would you please try recording the trace data with all sched events enabled and then check if plugin does something or not.
Again, thank you very much for your feedback! cheers, Yordan On 26.02.19 г. 6:35 ч., Phil Auld wrote:
Hi, I'm using kernel-shark to visualize some scheduler traces. I noticed that the visualization does not handle the sched_switch events as well as it might. The switch event is colored with the task being switched from, since that's the pid of the event itself. But this has the effect of leaving the wrong colored task "running" in the visualization until the next event by that task. If that next event is a sched_switch again you can have a case where the exact opposite of what happened is being visualized in kernel-shark. I could post a screenshot that illustrates this if that helps. Didn't want to add a binary attachment to my first post. It is especially glaring when switching to/from idle. I've tried both with and without the sched_events plugin enabled. There was no difference I could see. I'm not the slightest bit familiar with the code here, but I imagine there could be a way to get the pid from the next_pid field when the event is SchedEvent::Switch instead of the general PID field. If this is not of general interest I'd be happy to make the change only in my tree if anyone has a pointer or two on where to start. Cheers, Phil
|