-
Notifications
You must be signed in to change notification settings - Fork 576
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 per-sysnum latency and switch stats to the drmemtrace schedule_stats tool #7355
Comments
Updates the checked-in traces in clients/drcachesim/tests/drmemtrace.threadsig.x86.tracedir/ with new version with features missing from the old ones such as timestamps around each syscall. These features are needed for scheduler features. Updates various tests with "golden output" tuned to the old traces. Tries to reduce the amount of such output to make it a little easier to update next time. The new traces have more interleaving and longer wait times, necessitating some tweaks to tests that use the full scheduler to avoid them becoming too long or verbose. Issue: #7355
…7365) Updates the checked-in traces in clients/drcachesim/tests/drmemtrace.threadsig.x86.tracedir/ with new version with features missing from the old ones such as timestamps around each syscall. These features are needed for scheduler features. Updates various tests with "golden output" tuned to the old traces. Tries to reduce the amount of such output to make it a little easier to update next time. The new traces have more interleaving and longer wait times, necessitating some tweaks to tests that use the full scheduler to avoid them becoming too long or verbose. Issue: #7355
…x64.tracedir Updates the trace in tests/drmemtrace.threadsig-core-sharded.x64.tracedir so that it has the TRACE_ENTRY_VERSION_FREQUENT_TIMESTAMPS feature, needed for the new per-syscall latency feature in schedule_stats. Issue: #7355
This turns out to be impossible for core-sharded-on-disk traces as the scheduler has replaced the timestamps with values based on instruction and idle counts to this point. Since it processes the post-syscall record before switching, there have been no idles: so every syscall seemingly has latency 0. I'm probably just going to live with that as it would be complex to shift where the post-syscall timestamp appears; and if it were delayed, it gets hard to implement latency tracking in schedule_stats as it would need to track across threads which could move across cores and might require global locks. |
…istograms Augments the schedule_stats drmemtrace tool to keep two histograms for each system call number: one for latencies of system calls causing a context switch, and one for latencies not switching. Unfortunately the latencies are all 0 for core-sharded-on-disk traces; we live with that for now. Generalizes the histogram support through virtual methods create_histogram() and find_or_add_histogram() to make it easier to use different histograms in subclasses with all the new histograms being added here. Adds a unit test and augments top-level test expected output. Fixes #7355
The drmemtrace scheduler uses system call latency data to decide whether to switch. Having details on per-syscall-number latency and switch count would help analyze whether it's doing the right thing compared to the original workload. We can add this to the schedule_stats tool.
The text was updated successfully, but these errors were encountered: