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#6938 sched migrate: Enforce migration threshold at the start #7038

Merged
merged 2 commits into from
Oct 11, 2024

Conversation

derekbruening
Copy link
Contributor

Previously, a never-executed input could be moved to another output at any time, yet was still counted as a "migration". We change that here to consider a never-executed input to have executed at the initial simulation time seen on an output, so it will not be migrated until that threshold is met. An exception is the very first rebalance at init time for the initial allocation of inputs to outputs when inputs can be freely moved; this does not count as a migration.

Adds a unit test.

Issue: #6938

Previously, a never-executed input could be moved to another output at
any time, yet was still counted as a "migration".  We change that here
to consider a never-executed input to have executed at the initial
simulation time seen on an output, so it will not be migrated until
that threshold is met.  An exception is the very first rebalance at
init time for the initial allocation of inputs to outputs when inputs
can be freely moved; this does not count as a migration.

Adds a unit test.

Issue: #6938
assert(false);
std::vector<std::string> sched_as_string =
run_lockstep_simulation(scheduler, NUM_OUTPUTS, TID_BASE, /*send_time=*/true);
// We should see zero migrations.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add " ... even though C was moved to a different core than what it was initially assigned to"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wasn't moved, actually, which is what we want to test for. I changed this to "// We should see zero migrations since output #1 failed to steal C from output #0." I also augmented the comment above to say:

// We have 3 inputs and 2 outputs. We expect a round-robin initial assignment
// to put A and C on output #0 and B on #1.
// B will finish #1 and then try to steal C from A but should fail if initial
// migrations have to wait for the threshold as though the input just ran
// right before the trace started, which is how we treat them now.

@derekbruening
Copy link
Contributor Author

arm failure is raw-zlib which I think is #5635

@derekbruening derekbruening merged commit a6af579 into master Oct 11, 2024
16 of 17 checks passed
@derekbruening derekbruening deleted the i6938-migrate-never-ran branch October 11, 2024 20:06
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