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

A EDF scheduler based on enclaves #484

Open
wants to merge 19 commits into
base: main
Choose a base branch
from
Open

A EDF scheduler based on enclaves #484

wants to merge 19 commits into from

Conversation

erlingrj
Copy link
Collaborator

This PR is based of this: #424 but I merged in an updated reactor-c and I want to keep the existing PR for reference.

edwardalee and others added 16 commits April 20, 2024 12:19
@edwardalee
Start towards core and scheduling policy
2c3aec3
@edwardalee
Support cores target property
5665c83
@edwardalee
Support thread policy in target property
508a156
@edwardalee
Rough start on EDF priority assignment
ac69b82
@soyerefsane
implementation with LL and some shifting priority algorithm
d0f60c1
@edwardalee
Merge branch 'main' into retreat24
4038756
@edwardalee
Merge branch 'main' into retreat24
7bdea87
@fra-p
Initial implementation of EDF scheduler
b407667 
1. Implemented left-shifting of priorities when the right shift fails
2. Assigned maximum priority to worker threads waiting on the semaphone
to be woken up as soon as a thread signals on the semaphore
3. Slightly re-factored the EDF code
4. Added missing case of scheduling a reaction with shorter deadline
than the others currently being executed
5. Added print of error when the scheduling policy is not LF_SCHED_FAIR
but the program was not launched with sudo rights (cannot change the
scheduling policy)
@fra-p
Fixes to the EDF scheduler
e6af033 
1. Implemented abort when the number of threads exceeds the number of
priority values
2. Set the priority to 99 when sleeping with wait_until function
@edwardalee
Merge branch 'main' into retreat24
55843a4
@edwardalee
Merged with main and moved EDF to GEDF_NP
b2e77d2
@edwardalee
Formatting
77e03af
@edwardalee
Suppress unused variable warnings
ea41b75
@fra-p
Fixed GEDF scheduler after refactoring
ab9d708 
1. Fixed bug with thread ids not corresponding to the indices of the EDF
data structure
2. Fixed bug where initialize_lf_thread_id was called twice in the main
thread
@fra-p
Fixes to the GEDF scheduler
bdf5d36 
1. Set the mutex protocol to INHERIT to avoid unbounded blocking time of
the worker threads when operating on the EDF data structure
2. Lowered the maximum priority of worker threads to 98 to reserve 99
for watchdogs
3. Fixes to the shifting algorithm
4. More LOG prints for debugging
@erlingrj
Merge branch 'main' into retreat24
933a2e8
@erlingrj erlingrj added enhancement Enhancement of existing feature schedulers labels Sep 27, 2024
@erlingrj
Copy link
Collaborator Author

erlingrj commented Sep 28, 2024 •
edited
Loading

@edwardalee and @fra-p, I have been looking at the proposed algorithm today. It is not an easy algorithm to get exactly right and this is a great start! I have some general comments:

  1. We should improve the readability by splitting into more functions, maybe use a generic linked list also. There is also a segfault occurring in a federate test which must be resolved.

  2. I am worried that this approach might lead to starvation. This is because worker threads are doing work in the runtime/scheduler between invoking reactions while retaining the priority associated with the deadline of the reaction. I believe this could lead to starvation in special circumstances and that in general it can lead to a little unexpected timing.
    I believe that we must give the workers the maximum priority when they are doing runtime-stuff. This is unfortunate as they will preempt more important work, but if our runtime has little overhead it might be OK?

  3. It appears to be potentially alot of syscalls (lf_thread_set_priority) in the worst case when we do scheduling because we might need to shift the priorities of many threads. Since we are working with SCHED_FIFO we really only need three priorities:PRIO_RUNTIME=98 used when sleeping and possibly doing runtime work, PRIO_RUN=97 which means the thread should be executing, we should only ever have N threads with this priority, and finally PRIO_WAIT=96 which will always be preempted by any thread with PRIO_RUN.

What does this mean? It means that when a worker fetches a reaction or completes a reaction (which is the time it adds itself and removes itself from the linked list), he must verify that we have N threads with PRIO_RUN by either bumping others up or down.

A downside is that it wont work well SCHED_FAIR, and I think it can be valuable to use this to set niceness values for soft real-time systems.

Have you considered this approach? Am I missing something crucial here?

@edwardalee
Copy link
Contributor

All good points.
I think it's worth trying out the version with just a few priorities.
It would be much simpler...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
enhancement Enhancement of existing feature schedulers
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@erlingrj @edwardalee @soyerefsane @fra-p