Hi Yordan, On Tue, Feb 26, 2019 at 08:55:18AM -0800 Yordan Karadzhov (VMware) wrote: > 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. Yeah, if that's what the code does then that's what I hit. I pretty sure this trace is -e sched_switch -O trace_printk only. I'll set it back up and try to get another and see what the plugin does. > > Would you please try recording the trace data with all sched events > enabled and then check if plugin does something or not. > I'll let you know. Thanks for your time and the nice tool. Cheers, Phil > 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 > > > > --
|