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

Gracefully handle hotplug in scx_rusty #218

Merged
merged 2 commits into from
Apr 4, 2024
Merged

Gracefully handle hotplug in scx_rusty #218

merged 2 commits into from
Apr 4, 2024

Conversation

Byte-Lab
Copy link
Contributor

@Byte-Lab Byte-Lab commented Apr 4, 2024

The scx_rusty scheduler does not support hotplug, and expects a static
host topology throughout its runtime. Though the kernel does have
support for detecting hotplug events, we currently don't detect this in
the kernel, nor surface it to user space when it happens. Now that we
have scx_bpf_exit(), we can gracefully exit the kernel in the event of a
hotplug, and communicate to user space that it should restart the
scheduler.

This patch adds that support to scx_rusty. Note that this assumes that
we're running on a recent enough kernel that has scx_bpf_exit(). If it
doesn't, then we instead just error out of the kernel scheduler and exit
the application.

Newer kernels also support exiting gracefully with an exit code. Let's
update the UserExitInfo struct to also read and export this value.

Signed-off-by: David Vernet <[email protected]>
The scx_rusty scheduler does not support hotplug, and expects a static
host topology throughout its runtime. Though the kernel does have
support for detecting hotplug events, we currently don't detect this in
the kernel, nor surface it to user space when it happens. Now that we
have scx_bpf_exit(), we can gracefully exit the kernel in the event of a
hotplug, and communicate to user space that it should restart the
scheduler.

This patch adds that support to scx_rusty. Note that this assumes that
we're running on a recent enough kernel that has scx_bpf_exit(). If it
doesn't, then we instead just error out of the kernel scheduler and exit
the application.

Signed-off-by: David Vernet <[email protected]>
@Byte-Lab Byte-Lab requested a review from htejun April 4, 2024 19:54
@Byte-Lab Byte-Lab changed the title Support hotplug in scx_rusty Gracefully handle hotplug in scx_rusty Apr 4, 2024
@Byte-Lab Byte-Lab merged commit 9a8ed8a into main Apr 4, 2024
1 check passed
@Byte-Lab Byte-Lab deleted the rusty_hotplug branch April 4, 2024 21:04
@arighi
Copy link
Contributor

arighi commented Apr 4, 2024

It'd be nice if there was a generic way to apply this change automatically to all the schedulers, considering that most (all?) of them are not handling CPU hotplugging nicely at the moment, maybe a flag SCX_OPS_EXIT_ON_CPU_HOTPLUG or similar...

Anyway, this looks good to me for now, I'll do the same in scx_rustland_core.

@Byte-Lab
Copy link
Contributor Author

Byte-Lab commented Apr 4, 2024

Oh yeah, that's a good idea, definitely seems like this would be something generally useful. @htejun wdyt?

@htejun
Copy link
Contributor

htejun commented Apr 4, 2024

Yeah, it'd be nice to make this generic in scx_utils. Traits are tough to do with skels unfortunately, so we might have to do even more macros, which is a bit sad but not the end of the world.

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