| 1 | Linux Trace Toolkit |
| 2 | |
| 3 | Mathieu Desnoyers 17-05-2004 |
| 4 | |
| 5 | |
| 6 | 1. Read Requests Cases Study |
| 7 | |
| 8 | The goal of this document is to describe the typical behavior of viewers when |
| 9 | they request data to a process traceset. After the implementation of three |
| 10 | viewers, with different needs, the idea of their need for a trace processing API |
| 11 | is getting clearer. |
| 12 | |
| 13 | They are splitted in two different categories : the first one is the one where |
| 14 | the viewers select the events they need by specifying a time interval in the |
| 15 | traceset and the second one is where the viewers specify a start event by it's |
| 16 | position in the traceset and a certain amount of events it needs. |
| 17 | |
| 18 | |
| 19 | |
| 20 | Control Flow Viewer |
| 21 | |
| 22 | This viewer, consisting in a two dimensions graph, shows the different processes |
| 23 | as its y axis and the time as x axis. It's clear that it needs to get the events |
| 24 | by specifying a start time and an end time, constituing a time interval. |
| 25 | |
| 26 | |
| 27 | Detailed Events List |
| 28 | |
| 29 | This list has nothing to do with time : it shows the events one by one. It cares |
| 30 | about the quantity of events, not their time. |
| 31 | |
| 32 | It would be simple to get the events one by one if we were reading only one |
| 33 | tracefile (one cpu), but the way events are read through each trace |
| 34 | (monothically increasing time) makes it a little bit more difficult to specify |
| 35 | how to increment event position. We will determine how it could be done simply. |
| 36 | |
| 37 | Let's define an event position. It's composed of a tracefile number, a bloc |
| 38 | number and an index in the bloc. |
| 39 | |
| 40 | A viewer could ask for a specific event position as a start event. It would |
| 41 | specify a number of events it needs. As a first call, it could ask for tracefile |
| 42 | 0, bloc 0, event 0. Afterward, it can reuse information from events delivered to |
| 43 | keep track of the next events it needs. |
| 44 | |
| 45 | Now, let's see how process traceset could handle it. It would seek in the |
| 46 | traceset, searching the position number. |
| 47 | (need a new lttv_process_traceset_seek_position) |
| 48 | |
| 49 | Then, the viewer could simply call a process traceset function specifying a |
| 50 | number of events to get. |
| 51 | |
| 52 | The whole concept of numbering events would be hidden in the order in which the |
| 53 | process traceset gets the events in a monothically increasing time. |
| 54 | |
| 55 | We sould specify that a request from such a viewer should be of one more event |
| 56 | than needed : it would use the last event position to seek in the traceset for |
| 57 | the next read. So, for example, a request for 50 events would ask for 51, |
| 58 | keeping the event position of event 51. |
| 59 | |
| 60 | |
| 61 | |
| 62 | 2. Architecture |
| 63 | |
| 64 | Two different sets of API functions offered to read tracesets : |
| 65 | |
| 66 | lttv_process_traceset_seek_time |
| 67 | lttv_process_traceset_middle_time |
| 68 | |
| 69 | lttv_process_traceset_seek_position |
| 70 | lttv_process_traceset_middle_position |
| 71 | lttv_traceset_context_position_save |
| 72 | |
| 73 | |
| 74 | Of course, the typical use will be to call the seek_time with the middle_time, |
| 75 | and similarly for position functions, but the architecture does permit viewers |
| 76 | to mix calls to _time and _position functions. |
| 77 | |
| 78 | The position_save saves a position that can be used later to seek back to this |
| 79 | exact same position, with event granularity. This implies that the |
| 80 | process_traceset must deliver events with the same timestamp in a deterministic |
| 81 | manner. |
| 82 | |
| 83 | |
| 84 | 3. Implementation in tracecontext.c |
| 85 | |
| 86 | |
| 87 | - Type LttvTracesetContextPosition |
| 88 | |
| 89 | struct _LttvTracesetContextPosition { |
| 90 | LttEventPosition **tracefile_position; /* Position in each trace/tracefile */ |
| 91 | guint num_traces; /* Number of traces (for check) */ |
| 92 | guint num_tracefiles; /* Number of tracefiles (check) */ |
| 93 | GTree *pqueue; /* Copy of context pqueue */ |
| 94 | } |
| 95 | |
| 96 | with interfaces : |
| 97 | |
| 98 | lttv_traceset_context_position_save |
| 99 | (const LttvTracesetContext *context, |
| 100 | LttvTracesetContextPosition *pos); |
| 101 | |
| 102 | |
| 103 | Dependencies : |
| 104 | |
| 105 | - lttv_process_traceset_seek_position |
| 106 | - lttv_process_trace_seek_position |
| 107 | - ltt_tracefile_seek_position : already implemented |
| 108 | |
| 109 | lttv_process_traceset_seek_position will seek each trace to the right position. |
| 110 | Each trace will seek all of its tracesets to the right position. We keep |
| 111 | information about number of traces and tracefiles for extra integrity checking |
| 112 | when reloading the context. |
| 113 | |
| 114 | lttv_process_traceset_seek_position(LttvTracesetContext *self, |
| 115 | const LttvTracesetContextPosition *position); |
| 116 | |
| 117 | |
| 118 | - lttv_process_traceset_middle_position |
| 119 | We modify lttv_process_traceset_middle so that it takes as arguments : |
| 120 | (LttvTracesetContext *self, |
| 121 | const LttvTracesetContextPosition *end_position, |
| 122 | unsigned max_num_events) |
| 123 | |
| 124 | It's a simplification of the original function that will just read events until |
| 125 | the first criterion is fulfilled : the end_position is reached (we do not |
| 126 | deliver the event at the end_position) or the maximum number of events specified |
| 127 | is reached (we deliver the last event, corresponding to the maximum number of |
| 128 | events). The first event in the LttvTracesetContextPosition's pqueue will be |
| 129 | used as end_event. |
| 130 | |
| 131 | - lttv_process_traceset_seek_time : already implemented |
| 132 | |
| 133 | - lttv_process_traceset_middle_time |
| 134 | It's basically the same function as lttv_process_traceset_middle. We keep the |
| 135 | nb_events as a limit of events to read. We also keep the fact that, when the |
| 136 | maximum number of events is triggered, we also read the events that has the same |
| 137 | timestamp. This is useful for not losing events. The fact is that a viewer that |
| 138 | rely on time to select events it needs cannot have the granularity it needs to |
| 139 | select specific events from a bunch of events with the same time stamp. |
| 140 | |
| 141 | |
| 142 | |