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

Add new infeasible.rs crate #159

Merged
merged 2 commits into from
Feb 26, 2024
Merged

Add new infeasible.rs crate #159

merged 2 commits into from
Feb 26, 2024

Conversation

Byte-Lab
Copy link
Contributor

We want to avoid every scheduler implementation from having to implement
load balancing, but we also want to enable sufficient flexibility where
not every program has to have the same partition of scheduling domains,
etc. To enable this, a new load_balance crate is added which
encapsulates all of the logic for being given duty cycle and weight, and
performing the necessary math to adjust for infeasibility.

In addition, update scx_rusty to use the new crate.

@Byte-Lab
Copy link
Contributor Author

The CI failure is an scx_qmap timeout:

EXIT: runnable task stall (kworker/2:1[53] failed to run for 6.016s)
[   18.812322] ACPI: PM: Preparing to enter system sleep state S5
[   18.813521] kvm: exiting hardware virtualization
[   18.813805] reboot: Power down
FAIL: scx_qmap

scx_qmap is another pure example scheduler, so I think we can similarly put it in the no-timeout bucket.

rust/scx_utils/src/lib.rs Outdated Show resolved Hide resolved
rust/scx_utils/src/load_balance.rs Outdated Show resolved Hide resolved
rust/scx_utils/src/load_balance.rs Outdated Show resolved Hide resolved
rust/scx_utils/src/load_balance.rs Outdated Show resolved Hide resolved
rust/scx_utils/src/load_balance.rs Outdated Show resolved Hide resolved
rust/scx_utils/src/load_balance.rs Outdated Show resolved Hide resolved
rust/scx_utils/src/load_balance.rs Outdated Show resolved Hide resolved
rust/scx_utils/src/load_balance.rs Outdated Show resolved Hide resolved
rust/scx_utils/src/load_balance.rs Outdated Show resolved Hide resolved
@arighi
Copy link
Contributor

arighi commented Feb 24, 2024

The CI failure is an scx_qmap timeout:

EXIT: runnable task stall (kworker/2:1[53] failed to run for 6.016s)
[   18.812322] ACPI: PM: Preparing to enter system sleep state S5
[   18.813521] kvm: exiting hardware virtualization
[   18.813805] reboot: Power down
FAIL: scx_qmap

scx_qmap is another pure example scheduler, so I think we can similarly put it in the no-timeout bucket.

I agree, and scx_userland as well. See #160 .

@Byte-Lab
Copy link
Contributor Author

@htejun pushed a number of changes, please feel free to take another look. The comments that I haven't directly addressed are still left unresolved above, but everything else should have been addressed so let me know if you see otherwise.

@htejun
Copy link
Contributor

htejun commented Feb 24, 2024

I still find the name confusing given that all it does is solving infeasible weights (or is the plan to expand on it?) and it feels like leaving generic names like LoadCalc to actual scheduler implementations would be better, but this is definitely a nitpick. Please feel free to merge.

@htejun htejun self-requested a review February 24, 2024 19:34
We want to avoid every scheduler implementation from having to implement
the solution to the infeasible weights problem, but we also want to
enable sufficient flexibility where not every program has to have the
same partition of scheduling domains, etc. To enable this, a new
infeasible crate is added which encapsulates all of the logic for being
given duty cycle and weight, and performing the necessary math to adjust
for infeasibility.

Signed-off-by: David Vernet <[email protected]>
Now that we have a new 'infeasible' crate that abstracts the logic for
implementing the infeasible weights solution. Let's update rusty to use
it.

Signed-off-by: David Vernet <[email protected]>
@Byte-Lab
Copy link
Contributor Author

I still find the name confusing given that all it does is solving infeasible weights (or is the plan to expand on it?) and it feels like leaving generic names like LoadCalc to actual scheduler implementations would be better, but this is definitely a nitpick. Please feel free to merge.

Fair enough, I updated it to infeasible.rs. We can always further adjust it later if we need to.

@Byte-Lab Byte-Lab changed the title Add new load_balancer.rs crate Add new infeasible.rs crate Feb 26, 2024
@Byte-Lab Byte-Lab merged commit 4dfb898 into main Feb 26, 2024
1 check passed
@Byte-Lab Byte-Lab deleted the load_balancer branch February 26, 2024 17:15
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.

3 participants