You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 26, 2021. It is now read-only.
WA introduces a TRACE_START and TRACE_STOP markers in the trace when doing a run. trappy.wa should learn to get those and, using the abs_window feature of the Run object, limit the trace to that.
Note: Run.normalize_time() should probably need to accept a basetime parameter again.
The text was updated successfully, but these errors were encountered:
However, @derkling suggests to make it a lot more general than this. Instead of having to parse the trace again for every new window of markers that you want to look at, he suggests having an API that allows you to get a window view of the trace out of the full trace. For example, assuming that Phase X start and Phase X stop trace markers were injected in the trace when different phases of a workload start/stop, we could do:
trace=trappy.FTrace(path)
phase1_trace=trace.betweenMarkers("Phase 1 start", "Phase 1 stop")
phase1_trace.sched_switch.data_frame# Would get a data frame for the sched_switch events that happen only in phase 1
The object returned by betweenMarkers() should have the same interface as that of trappy.FTrace(). For the end user, it should behave exactly the same. Internally, it could be an instance trappy.FTrace or a subclass of it.
betweenMarkers() should renormalize the time by default. We can make that a parameter later if there is demand for it.
WA introduces a TRACE_START and TRACE_STOP markers in the trace when doing a run.
trappy.wa
should learn to get those and, using theabs_window
feature of theRun
object, limit the trace to that.Note:
Run.normalize_time()
should probably need to accept a basetime parameter again.The text was updated successfully, but these errors were encountered: