-
-
Notifications
You must be signed in to change notification settings - Fork 606
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
sched: Support POSIX's SCHED_RR scheduling policy #1338
base: master
Are you sure you want to change the base?
Changes from all commits
9fdae8c
2535721
e9ea1a0
3c27113
002e0a9
8db3444
b2f1957
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -276,6 +276,10 @@ void cpu::reschedule_from_interrupt(bool called_from_yield, | |
} | ||
thread* p = thread::current(); | ||
|
||
if (p->_realtime.has_slice() && p->_realtime._priority > 0) { | ||
p->_realtime._run_time += interval; | ||
} | ||
|
||
const auto p_status = p->_detached_state->st.load(); | ||
assert(p_status != thread::status::queued); | ||
|
||
|
@@ -295,8 +299,18 @@ void cpu::reschedule_from_interrupt(bool called_from_yield, | |
} else if (!called_from_yield) { | ||
auto &t = *runqueue.begin(); | ||
if (p->_realtime._priority > 0) { | ||
// Only switch to a higher-priority realtime thread | ||
if (t._realtime._priority <= p->_realtime._priority) { | ||
// If the threads have the same realtime priority, then only reschedule | ||
// if the currently executed thread has exceeded its time slice (if any). | ||
if (t._realtime._priority == p->_realtime._priority && | ||
((!p->_realtime.has_slice() || p->_realtime.has_remaining()))) { | ||
#ifdef __aarch64__ | ||
return switch_data; | ||
#else | ||
return; | ||
#endif | ||
// Otherwise, don't switch to a lower-priority realtime thread, | ||
// no matter how much time slice was used by the running thread. | ||
} else if (t._realtime._priority < p->_realtime._priority) { | ||
#ifdef __aarch64__ | ||
return switch_data; | ||
#else | ||
|
@@ -336,15 +350,27 @@ void cpu::reschedule_from_interrupt(bool called_from_yield, | |
p->_detached_state->st.store(thread::status::queued); | ||
|
||
if (!called_from_yield) { | ||
// POSIX requires that if a real-time thread doesn't yield but | ||
// rather is preempted by a higher-priority thread, it be | ||
// reinserted into the runqueue first, not last, among its equals. | ||
enqueue_first_equal(*p); | ||
if (p->_realtime.has_slice() && !p->_realtime.has_remaining()) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, maybe we need to check if realtime.priority>0 because maybe has_slice() just records some old setting and it's not in use now? Or, maybe, for simplicity, we should just ensure that if the real-time priority is ever set to 0, then slice is also set to 0? |
||
// The real-time thread has exceeded it's time slice, enqueue | ||
// it at the end among its equals and reset the time slice. | ||
enqueue(*p); | ||
p->_realtime.reset_slice(); | ||
} else { | ||
// POSIX requires that if a real-time thread doesn't yield but | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So this means that if the current thread There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I think it's correct. If we got here it means p was preempted. If it still has remaining time, it means it was preempted by a higher-priority realtime thread but when that higher-priority thread doesn't want to run, this thread p should continue running and continue its current time slice. The documentation says: "A SCHED_RR thread that has been preempted by a higher priority thread and subsequently resumes execution as a running thread will complete the unexpired portion of its round-robin time quantum.". It should be the first one in its priority group to run (and therefore enqueue_first_equal()) just like when no time slices existed. |
||
// rather is preempted by a higher-priority thread, it be | ||
// reinserted into the runqueue first, not last, among its equals. | ||
enqueue_first_equal(*p); | ||
} | ||
} | ||
|
||
trace_sched_preempt(); | ||
p->stat_preemptions.incr(); | ||
} else { | ||
// p is no longer running, if it has a realtime slice reset it. | ||
if (p->_realtime.has_slice()) { | ||
p->_realtime.reset_slice(); | ||
} | ||
Comment on lines
+369
to
+372
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is not entirely clear to me if the slice should be reset if the thread is no longer runnable (e.g. because of blocking I/O). POSIX does not explicitly describe when the slice should be reset. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I'm also not sure, but think this if is right. I think the idea of the time slice is to make sure that a single thread never in its priority group never runs more than 1ms (for example) without letting other threads in its group run. But if the thread blocks or yields voluntarily (I believe this if covers both cases, right?), then it gives some other thread a chance to run and it too has a chance to run for a whole time-slice, so it's only fair that this thread's time slice is reset to zero. I think. |
||
|
||
// p is no longer running, so we'll switch to a different thread. | ||
// Return the runtime p borrowed for hysteresis. | ||
p->_runtime.hysteresis_run_stop(); | ||
|
@@ -392,6 +418,9 @@ void cpu::reschedule_from_interrupt(bool called_from_yield, | |
} else { | ||
preemption_timer.set_with_irq_disabled(now + preempt_after); | ||
} | ||
} else if (n->_realtime.has_slice()) { | ||
assert(n->_realtime.has_remaining()); | ||
preemption_timer.set_with_irq_disabled(now + n->_realtime.remaining()); | ||
} | ||
|
||
if (app_thread.load(std::memory_order_relaxed) != n->_app) { // don't write into a cache line if it can be avoided | ||
|
@@ -920,10 +949,6 @@ unsigned thread::realtime_priority() const | |
|
||
void thread::set_realtime_time_slice(thread_realtime::duration time_slice) | ||
{ | ||
if (time_slice > 0) { | ||
WARN_ONCE("set_realtime_time_slice() used but real-time time slices" | ||
" not yet supported"); | ||
} | ||
_realtime._time_slice = time_slice; | ||
nmeum marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,128 @@ | ||
#include <atomic> | ||
#include <string> | ||
#include <iostream> | ||
#include <osv/sched.hh> | ||
|
||
#define TIME_SLICE 100000000 | ||
|
||
static std::string name = "tst-thr-wrk"; | ||
static int tests = 0, fails = 0; | ||
|
||
static void report(bool ok, std::string msg) | ||
{ | ||
++tests; | ||
fails += !ok; | ||
std::cout << (ok ? "PASS" : "FAIL") << ": " << msg << "\n"; | ||
} | ||
|
||
static int fac(int n) | ||
{ | ||
if (n == 0) { | ||
return 0; | ||
} else if (n == 1) { | ||
return 1; | ||
} else { | ||
return fac(n - 1) + fac(n - 2); | ||
} | ||
} | ||
|
||
bool runtime_equalized() | ||
{ | ||
constexpr int num_threads = 5; | ||
constexpr int switches = 3; | ||
static std::atomic<bool> stop_threads; | ||
sched::thread *threads[num_threads]; | ||
|
||
sched::cpu *c = sched::cpu::current(); | ||
for (int i = 0; i < num_threads; i++) { | ||
threads[i] = sched::thread::make([&]{ | ||
while (!stop_threads.load()) { | ||
fac(10); | ||
} | ||
}, sched::thread::attr().name(name)); | ||
|
||
threads[i]->pin(c); | ||
threads[i]->set_realtime_priority(1); | ||
threads[i]->set_realtime_time_slice(std::chrono::nanoseconds(TIME_SLICE)); | ||
threads[i]->start(); | ||
} | ||
|
||
auto runtime = std::chrono::nanoseconds(TIME_SLICE * num_threads * switches); | ||
sched::thread::sleep(runtime); | ||
stop_threads = true; | ||
|
||
bool ok = true; | ||
long prev_switches = -1; | ||
for (int i = 0; i < num_threads; i++) { | ||
long switches = threads[i]->stat_switches.get(); | ||
if (prev_switches != -1 && prev_switches != switches) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Am I correct that you want all threads to have exactly the same number of context switches? How can we be confident of this - can't one happen to have one more than the others because of some inaccuracy or something? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes. My thinking was: If we assign each thread a time slice of size Maybe I am missing something obvious, but I haven't seen this test fail yet. However, since this is not a hard-realtime operating systems I assume we could see delays here and there in the scheduler? We can also make the comparison fuzzy, allowing the amount of expected context switches to be off by 1 or 2? |
||
ok = false; | ||
break; | ||
} | ||
prev_switches = switches; | ||
} | ||
|
||
for (int i = 0; i < num_threads; i++) { | ||
delete threads[i]; | ||
} | ||
|
||
return ok; | ||
} | ||
|
||
bool priority_precedence() | ||
{ | ||
static std::atomic<bool> high_prio_stop; | ||
sched::thread *high_prio = sched::thread::make([&]{ | ||
while (!high_prio_stop.load()) { | ||
fac(10); | ||
} | ||
}); | ||
|
||
static std::atomic<bool> low_prio_stop; | ||
sched::thread *low_prio = sched::thread::make([&]{ | ||
while (!low_prio_stop.load()) { | ||
fac(10); | ||
} | ||
}); | ||
|
||
sched::cpu *c = sched::cpu::current(); | ||
high_prio->pin(c); | ||
low_prio->pin(c); | ||
|
||
high_prio->set_realtime_priority(2); | ||
low_prio->set_realtime_priority(1); | ||
|
||
// The higher priority thread has a time slice, but since there is no other thread | ||
// with the same priority, it should monopolize the CPU and lower_prio shouldn't run. | ||
high_prio->set_realtime_time_slice(sched::thread_realtime::duration(TIME_SLICE)); | ||
|
||
high_prio->start(); | ||
low_prio->start(); | ||
|
||
auto runtime = std::chrono::nanoseconds(TIME_SLICE * 3); | ||
sched::thread::sleep(runtime); | ||
|
||
// Since both threads are pinned to the CPU and the higher priority | ||
// thread is always runnable, the lower priority thread should starve. | ||
bool ok = high_prio->thread_clock().count() > 0 && | ||
low_prio->thread_clock().count() == 0; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm a bit worried that it's theoretically possible that although you start()ed the high prio thread first and only then the low_prio one, maybe the low prio one got to run for a microsecond before the high prio one so its thread clock will not be exactly zero. But maybe in practice it doesn't happen... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This test can also have the opposite problem. If I understand correctly your TIME_SLICE is absolutely tiny, 0.1 milliseconds, and after starting high_prio and low_prio you only sleep 3 times that, i.e., 0.3 milliseconds, so it is theoretically possible that the test will pass even without any realtime priorities or anything, just because we let the first-ran highprio thread run for 0.3 milliseconds straight. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I increased it further in 3c27113
Note: They are both pinned to same CPU so the higher prio one should also be first in the CPU runqueue and should always be runnable so I am not sure under which scenario the lower prio one would get the CPU. However, I believe you have more expertise with the scheduling code. We can also discard this test case. What test cases would you like to see instead for |
||
|
||
low_prio_stop = true; | ||
high_prio_stop = true; | ||
|
||
delete high_prio; | ||
delete low_prio; | ||
|
||
return ok; | ||
} | ||
|
||
int main(int ac, char** av) | ||
{ | ||
// Ensure that the main thread doesn't starve. | ||
sched::thread *cur = sched::thread::current(); | ||
cur->set_realtime_priority(10); | ||
|
||
report(runtime_equalized(), "runtime_equalized"); | ||
report(priority_precedence(), "priority_precedence"); | ||
std::cout << "SUMMARY: " << tests << " tests, " << fails << " failures\n"; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So all this means we are going to keep the current thread
p
running should stay running if_time_slice
is 0 (run 'forever' until yields or waits) OR there is still time left to run per its_time_slice
, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
p->_realtime.has_slice()
checks if it has a time slice (i.e._time_slice
!= 0),p->_realtime.has_remaining()
checks if there is still time remaining on the slice (if it has one).Note that, even if the thread has exceeded its time slice it may still be selected to run again if there is no thread with a higher priority. Hence, the priority comparison in the if condition.