Skip to content
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

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

abhinav92003
Copy link
Contributor

@abhinav92003 abhinav92003 commented Feb 14, 2025

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

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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).

Copy link
Contributor Author

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
Copy link
Contributor

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.
Copy link
Contributor

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()
Copy link
Contributor

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);
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants