scx_loader: Add scheduler loader via system DBUS interface #565
Conversation
convert scheduler crate into lib+bin crate, to be able to use(load/unload) scheduler by other crates required for sched-ext#565
|
What are the benefits of turning each scheduler into library instead of just having a dbus attached launcher? The cost is that this bifurcates how schedulers are run depending on how it's run which does make things a bit more obscure. So, my preference would be layering on top. |
Generally loading schedulers as native code(crates), is more reliable and self-contained, allows for better integration with schedulers if needed. Although I will rework In future some schedulers can adjusted separately to run as crates instead of child proc if needed |
vnepogodin
force-pushed
the
feature/scx-loader
branch
from
67e0bcf to
b050a5f
Compare
scheds/rust/scx_loader/meson.build
Outdated
| env: cargo_env, | ||
| depends: sched_deps, | ||
| build_by_default: false, | ||
| build_always_stale: true) |
There was a problem hiding this comment.
If you pull in the latest, scheds/rust/meson.build has an example of how to hook this up from the parent directory. I think we just need to add the same template to rust/meson.build, specify scx_loader as the only target (as others are libraries) and make the top level meson.build to descend into the rust directory.
There was a problem hiding this comment.
I'm tried to add that. seems to work)
Although installation of dbus spec is a bit messy :)
|
Also, would it make sense to make the name a bit more specific - e.g. |
vnepogodin
force-pushed
the
feature/scx-loader
branch
6 times, most recently
from
ea4456f to
7c2822f
Compare
I think it would be a bit verbose, and if we would add some schedulers as crates would require rename again. I don't think we need both loaders at the same time in that case |
vnepogodin
force-pushed
the
feature/scx-loader
branch
4 times, most recently
from
d3164af to
ff65cba
Compare
|
|
||
| # Install bus spec for scx_loader | ||
| if [ "$name" = "scx_loader" ]; then | ||
| install -D -m 0644 "${source_dir}/org.scx.Loader.conf" "${DESTDIR}/usr/share/dbus-1/system.d/org.scx.Loader.conf" |
There was a problem hiding this comment.
I wonder whether the right thing to do is invoking cargo install with the right parameters. e.g. if someone does cargo install scx_loader, it should also install the dbus-1 file too, right?
There was a problem hiding this comment.
yeah it's required. hmm I don't think its possible to install custom files with cargo install. would be great)
There was a problem hiding this comment.
You can include custom files in the crate via include, see for example https://github.com/sched-ext/scx/blob/main/rust/scx_rustland_core/Cargo.toml#L26. But you can't arbitrarily install them anywhere in the system I guess...
There was a problem hiding this comment.
Looks like not possible yet to install custom files with cargo install, but possible with tools like cargo xtask
There was a problem hiding this comment.
I see. Let's leave as-is for the time being.
| env: cargo_env, | ||
| depends: sched_deps, | ||
| build_by_default: true, | ||
| build_always_stale: true) |
There was a problem hiding this comment.
I would make it explicitly build only rust_binaries. No need to build libraries separately by default.
There was a problem hiding this comment.
do you mean to set build_always_stale to false on rust_binaries?
There was a problem hiding this comment.
There need to be two targets:
- The default target which gets triggered by default.
- Package-specific target so that users can do
meson compile -C build $TARGET.
We don't want to build libraries by default for 1) but want to provide (we weren't before) individual targets for 2).
So, the default target should do cargo build -p scx_loader. It will probably look something like:
rust_libs = [ ... ]
rust_bins = [ ... ]
rust_all = rust_libs + rust_bins
// `-p bin` for each in rust_bin to cargo args
custom_target('rust_binaries', ...)
foreach package in rust_all
custom_target(package, ...)
Please feel free to leave it as is. I can update afterwards too.
There was a problem hiding this comment.
Oh. I'll leave it as is then )
vnepogodin
force-pushed
the
feature/scx-loader
branch
from
ff65cba to
4d770e1
Compare
|
@htejun I'm currently thinking if we should provide additional systemd service for |
This pull request introduces a utility with a DBUS interface to initiate schedulers with any flags potentially supported by a specific scheduler. It accomplishes this by starting schedulers as child processes.
The scx_loader offers the following features:
StartSchedulermethod accepts the scx_name of the scheduler (e.g., "scx_rusty" or "scx_bpfland") and the scheduler mode (profile) as an enumerated value (raw input expects an unsigned integer).StartSchedulerWithArgsmethod accepts the scx_name of the scheduler and the scheduler CLI arguments.StopSchedulermethod can be used to terminate a running scheduler.CurrentSchedulerproperty indicates the currently active scheduler; if none is running, it returns "unknown." (Note: This property may be modified in the future to return an error instead.)SchedulerModeproperty provides information about the currently set scheduler mode.SupportedSchedulersproperty provides the list of currently supported schedulers.