ARM-software / trappy

This repository has moved to https://gitlab.arm.com/tooling/trappy
Apache License 2.0
60 stars 39 forks source link

[EventPlot] disappearing events while zooming in #219

Closed mdigiorgio closed 8 years ago

mdigiorgio commented 8 years ago

When zooming in a certain region of the plot sometimes some events disappear. The following two pictures show the issue:

As you can see all events related to SurfaceFlinger task disappeared.

JaviMerino commented 8 years ago

Do you have trace for this, or some way of reproducing it?

mdigiorgio commented 8 years ago

I pushed a branch on my fork with the data and a notebook to reproduce it: https://github.com/mdigiorgio/trappy/tree/eventplot-tasks_latency

mdigiorgio commented 8 years ago

Use the following csv files with the code below...

data.csv.txt data_sf.csv.txt

rendert_df = pd.read_csv('./data.csv')
sf_df = pd.read_csv('./data_sf.csv')

rendert_df.set_index('Time', inplace=True)
sf_df.set_index('Time', inplace=True)

def get_events(task_df, task_name):
    wakeup = task_df[(task_df.curr_state == 'W') & (task_df.next_state == 'A')]
    running = task_df[(task_df.curr_state == 'A')]
    preempt = task_df[(task_df.curr_state.isin(['R', 'R+'])) & (task_df.next_state == 'A')]
    suspend = task_df[(task_df.curr_state == 'D') & (task_df.next_state == 'W')]

    t_end = wakeup['t_start'] + wakeup['t_delta']
    w_event = [[start, end, task_name] for start, end in t_end.iteritems()]
    t_end = running['t_start'] + running['t_delta']
    r_event = [[start, end, task_name] for start, end in t_end.iteritems()]
    t_end = preempt['t_start'] + preempt['t_delta']
    p_event = [[start, end, task_name] for start, end in t_end.iteritems()]
    t_end = suspend['t_start'] + suspend['t_delta']
    u_event = [[start, end, task_name] for start, end in t_end.iteritems()]

    return r_event, w_event, p_event, u_event

rt_events = get_events(rendert_df, "RenderThread")
sf_events = get_events(sf_df, "SurfaceFlinger")

EVENTS = {}
EVENTS["Running"] = rt_events[0] + sf_events[0]
EVENTS["WakeupLat"] = rt_events[1] + sf_events[1]
EVENTS["PreemptLat"] = rt_events[2] + sf_events[2]
EVENTS["SuspendedUnint"] = rt_events[3] + sf_events[3]

x_max = max(sf_df.index.max(), rendert_df.index.max())

trappy.EventPlot(EVENTS,
                 keys=EVENTS.keys,
                 lanes=["RenderThread", "SurfaceFlinger"],
                 domain=[0,x_max]
                ).view()
farleylai commented 8 years ago

Hi,

I also encountered a similar problem. The events in some lanes become blank after zoom in as shown in the following figures. Strangely, the right end might show up. The full html with the dataset embedded is also attached. It refers to the js sources remotely to ensure the latest version. Any ideas?

Before

before

After

after

All in one html in a zip 10_10_25_25-5-2-0-0-events-nosched.html.zip

sinkap commented 8 years ago

So, I think I know what is happening here. The timeline plot was designed to have one "key" running in one "lane". Here you have the "queueing" key running in multiple lanes and this confuses the filtering logic. I imagined the each event to be only present in one lane at a time, much like a single PID can be only on a single CPU.

I can try to fix this. But not sure. Can you generate your gevents in such a way that you have unique names for queuing for each Domain, eg. queueing_domain_1. It should work then..

sinkap commented 8 years ago

Well, I got it to work. Will submit a patch for this. Thanks @mdigiorgio and @farleylai for noticing this.

sinkap commented 8 years ago
screen shot 2016-08-20 at 01 57 38
sinkap commented 8 years ago

@mdigiorgio in your case too, you could have both kind of events in each lane, For example surfaceflinger and renderThread could both be "Running" Simultaneously. Anyhow, the new patch should fix it.

farleylai commented 8 years ago

Thanks for quick responses. The use case is to align application thread events (per domain exec/queuing) with the kernel ftrace events. Though it makes sense to add prefix/suffix to each domain for distinction, the new patch should make it intuitive for visualization. BTW, if possible, it would be handy to allowing specifying some pre-defined color maps that give visual appeal.

sinkap commented 8 years ago

@farleylai The colour mapping is possible. Can you take a look at the documentation in

https://github.com/ARM-software/trappy/blob/master/doc/InteractivePlotter.ipynb

This was recently added:

        :param color_map: A mapping between events and colours
            ::
                { "<name1>" : "colour1",
                  .
                  .
                  .
                  "<nameN>" : "colourN"
                }
            Colour string can be:
            - Colour names (supported colours are listed in
            https://www.w3.org/TR/SVG/types.html#ColorKeywords)
            - HEX representation of colour, like #FF0000 for "red", #008000 for
            "green", #0000FF for "blue" and so on
        :type color_map: dict
sinkap commented 8 years ago

You can also check out our API Reference documentation at

https://pythonhosted.org/TRAPpy/trappy.plotter.EventPlot.html

farleylai commented 8 years ago

Thanks. I am aware the programmer can specify a custom color map. But it is not necessarily visually appealing in view of a large number of events. The pre-defined maps are meant to be designed by someone with stronger artistic sense. Alternatively, having a list of event checkboxes for the viewer to disable/enable some events of interest might be helpful for dynamic visualization. So far, I just try to generate different versions of the event plots.

sinkap commented 8 years ago

For dynamic filtering we already have an issue #47 but I am still not sure about what kind of UI controllers would be suitable here. Checkboxes can get messy for a large number of events, drop down lists only allow for one event, What we can do is a text box where you can have comma separated strings to filter the events in the UI. WDYT?

sinkap commented 8 years ago

Also we can move this discussion in #47 since this is not in the scope of this one.