-
Notifications
You must be signed in to change notification settings - Fork 571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add timestamps-of-interest drmemtrace scheduler feature #6844
Labels
Comments
derekbruening
added a commit
that referenced
this issue
Jun 14, 2024
Adds a new feature times_of_interest to the drmemtrace scheduler. This allows specifying regions of interest via timestamps, which cut across all inputs in a workload, providing for a consistent starting point across all threads. The feature requires a cpu schedule file which is used to build a mapping from timestamps to instruction ordinals. The mapping is not perfect due to collapsed consecutive entries and coarse-grained timestamps so interpolation is used in between known points. Adds a unit test. Adds a new analyzer command-line option -skip_to_timestamp which sets a single time-of-interest in the scheduler. Adds a test using the checked-in threadsig x86_64 trace. Fixes #6844
derekbruening
added a commit
that referenced
this issue
Jun 20, 2024
Fixes two misspellings of "timestamp" in the docs for the new times_of_interest drmemtrace scheduler feature. Issue: #6844
derekbruening
added a commit
that referenced
this issue
Jun 20, 2024
Fixes two misspellings of "timestamp" in the docs for the new times_of_interest drmemtrace scheduler feature. Issue: #6844
derekbruening
added a commit
that referenced
this issue
Jul 18, 2024
…tion Adds a comment explaining that rounding down when interpolating for the drmemtrace skip-to-timestap feature is the right thing to do, as it ensures we include a system call that spans the start time and thus will correctly block/unschedule up front. Issue: #6844
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The drmemtrace scheduler has a regions-of-interest feature to specify subsets of a trace via instruction ordinal ranges. However, for a many-threaded trace, if these subsets should cut across all threads that were active at the same time during traces, computing the instruction ordinals for each thread requires a separate pass over every thread's trace. A simpler interface would be to provide a single timestamp range for the whole workload and have the scheduler use the recorded schedule file to map that to per-thread instruction ordinals.
The text was updated successfully, but these errors were encountered: