-
Notifications
You must be signed in to change notification settings - Fork 574
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
i#7157: Inject syscall templates dynamically in scheduler #7277
base: master
Are you sure you want to change the base?
Conversation
Adds support to the drmemtrace scheduler for injecting system call trace templates dynamically during scheduling. This obviates the need to create a separate statically-injected trace with system call trace templates. Reuses context switch trace injection code to the extent possible. Adds a new analyzer flag -sched_syscall_file and new scheduler_options_t fields to allow specifying the system call trace template file. Issue: #7157
trace_marker_type_t marker_type; | ||
uintptr_t marker_value; | ||
// Good to queue the injected records at this point, because we now surely will | ||
// be done with TRACE_MARKER_TYPE_SYSCALL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be moved inside process_marker()? It feels out of place here. If for some reason it has to be here: please make a new helper function as this containing next_record() function is already long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be moved inside process_marker()?
I don't think so because it is better to inject the syscall records when we know for sure that the syscall marker is going to be presented to the caller. I see there are various cases above where we may not want to do that yet (due to ROI, needs_new_input).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make a new helper function as this containing next_record() function is already long.
Added a finalize_next_record which can hold these "final" actions.
* Input file containing template sequences of kernel system call code. | ||
* Each sequence must start with a #TRACE_MARKER_TYPE_SYSCALL_TRACE_START | ||
* marker and end with #TRACE_MARKER_TYPE_SYSCALL_TRACE_END. | ||
* The values of each marker must hold the system call number value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/values/value/
* multiple system calls are concatenated into a single file. | ||
* Each sequence should be in the regular offline drmemtrace format. | ||
* Each sequence is inserted into the output stream after all | ||
* #TRACE_MARKER_TYPE_SYSCALL markers with the same value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like nothing is inserted until all markers in the trace have been passed: so if there are 4 SYS_open, after the 4th one we then insert a sequence.
How about s/after all/after a/
(and s/markers/marker/
). Or maybe better "Whenever a #TRACE_MARKER_TYPE_SYSCALL marker is encountered, if a corresponding sequence with the same marker value exists it is inserted into the output stream after the #TRACE_MARKER_TYPE_SYSCALL marker."
template <> | ||
template <> | ||
typename scheduler_tmpl_t<memref_t, reader_t>::switch_type_t | ||
scheduler_impl_tmpl_t<memref_t, reader_t>::default_kernel_sequence_key() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm: I know default constructors sometimes create invalid values, but not always. "default" doesn't necessarily imply "invalid" or "sentinel", IMHO. I would vote for s/default/invalid/. That makes it clear with no ambiguity.
@@ -409,6 +409,9 @@ template <typename RecordType, typename ReaderType> class scheduler_impl_tmpl_t | |||
update_switch_stats(output_ordinal_t output, input_ordinal_t prev_input, | |||
input_ordinal_t new_input); | |||
|
|||
void | |||
process_marker(RecordType record, output_ordinal_t output); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just moving in_syscall_code does seem reasonable. I assume you're not proposing counting the injected sequence as part of the input stream.
Adds support to the drmemtrace scheduler for injecting system call trace templates dynamically during scheduling. This obviates the need to create a separate statically-injected trace with system call trace templates.
Reuses context switch trace injection code to the extent possible.
Adds a new analyzer flag -sched_syscall_file and new scheduler_options_t fields to allow specifying the system call trace template file.
Adds a mock system call template file generated using the burst_syscall_inject test (slightly modified to use sysnums that match the checked-in test trace).
Adds various unit tests: a new scheduler unit test that verifies dynamic syscall trace injection and its effect on scheduling, analyzer tests that use -sched_syscall_file for dynamic injection in core-sharded and non-core-sharded modes, and an invariant checker test on the added mock system call template file.
Issue: #7157