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.

Sign up for GitHub

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

Jump to bottom

Fine-tune unified scheduler loops by select_biased #1437

Merged
merged 1 commit into from
May 22, 2024
Merged

Fine-tune unified scheduler loops by select_biased #1437

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 3 additions & 10 deletions unified-scheduler-pool/src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@
use qualifier_attr::qualifiers;
use {
assert_matches::assert_matches,
crossbeam_channel::{self, never, select, Receiver, RecvError, SendError, Sender},
crossbeam_channel::{self, never, select_biased, Receiver, RecvError, SendError, Sender},
dashmap::DashMap,
derivative::Derivative,
log::*,
Expand Down Expand Up @@ -622,10 +622,6 @@ impl<S: SpawnableScheduler<TH>, TH: TaskHandler> ThreadManager<S, TH> {
// isn't implemented. The former is due to complex implementation and the later is due to
// delayed (NOT real-time) processing, which is against the unified scheduler design goal.
//
// Finally, note that this optimization should be combined with biased select (i.e.
// `select_biased!`), which isn't for now... However, consistent performance improvement is
// observed just with this priority queuing alone.
//
// Alternatively, more faithful prioritization can be realized by checking blocking
// statuses of all addresses immediately before sending to the handlers. This would prevent
// false negatives of the heuristics approach (i.e. the last task of a run doesn't need to
Expand Down Expand Up @@ -751,9 +747,6 @@ impl<S: SpawnableScheduler<TH>, TH: TaskHandler> ThreadManager<S, TH> {
let dummy_unblocked_task_receiver =
dummy_receiver(state_machine.has_unblocked_task());

// (Assume this is biased; i.e. select_biased! in this crossbeam pr:
// https://github.com/rust-lang/futures-rs/pull/1976)
//
// There's something special called dummy_unblocked_task_receiver here.
// This odd pattern was needed to react to newly unblocked tasks from
// _not-crossbeam-channel_ event sources, precisely at the specified
Expand All @@ -764,7 +757,7 @@ impl<S: SpawnableScheduler<TH>, TH: TaskHandler> ThreadManager<S, TH> {
// consistent. Note that unified scheduler will go
// into busy looping to seek lowest latency eventually. However, not now,
// to measure _actual_ cpu usage easily with the select approach.
select! {
select_biased! {
recv(finished_blocked_task_receiver) -> executed_task => {
let executed_task = executed_task.unwrap();

Expand Down Expand Up @@ -828,7 +821,7 @@ impl<S: SpawnableScheduler<TH>, TH: TaskHandler> ThreadManager<S, TH> {
let finished_idle_task_sender = finished_idle_task_sender.clone();

move || loop {
let (task, sender) = select! {
let (task, sender) = select_biased! {
recv(runnable_task_receiver.for_select()) -> message => {
if let Some(task) = runnable_task_receiver.after_select(message.unwrap()) {
(task, &finished_blocked_task_sender)
Expand Down
Loading