-
-
Notifications
You must be signed in to change notification settings - Fork 793
Fix querying if a process is read to run #4688
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
base: master
Are you sure you want to change the base?
Conversation
bradjc
left a comment
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.
Approach 1 would be a lot simpler. Not sure I'm convinced it's worth it to modify the State.
Agree, but |
brghena
left a comment
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.
This is good overall. A couple of small things, notably I think there's a logic bug.
| /// Modify the yielded-for-state to signal that there is an upcall | ||
| /// scheduled for `UpcallId`. | ||
| /// | ||
| /// This will fail (i.e. not do anything) if the process was not previously | ||
| /// running. | ||
| fn set_yielded_for_state_ready(&self, upcall_id: UpcallId); | ||
|
|
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.
Can we add this to enqueue_task rather than adding a new API?
Pull Request Overview
This pull request fixes the way in which
ProcessStandardverifies if a process is ready to run. Additionally it changes the order in whichProcess::readyverifies the states, to return faster if a process isRunning.The
Process::readyfunction was designed when theYieldedForstate did not exist. The function decides that a process is able to do work if it is in theRunningstate of if it has any scheduled tasks. This is correct if the process isYielded, as any task can be dispatched to the process.The function does not take into account that the process might be in the
YieldedForstate, where only a specific task can be dispatched (returned) to the process.This has a consequence for the scheduling. Suppose we have a scheduler that picks the process that has performed the minimum number of syscalls or has exceeded its timeslice the least times:
YieldedForstate waiting for an action from process B (probably a custom IPC call implemented in a capsule)Process::readyfor process A returnstrueas there are additional tasks in the queue, but not the one that the process yielded forThe
Process::readyfunction should take into account theYieldedForcase. There are two solutions here:Process::readyiterates the tasks and figures out ifYieldedForcan returnYieldedForhas an extra payload to store whether it can return or not andProcess::readyreads that payloadyield-wait-for, the queue is verified and the extra payload is set accordinglyThis pull request uses the second approach, as it only needs to verify the tasks list when
yield-wait-foris called or when an upcall is scheduled. The first approach would iterate the tasks list at every timeProcess::readyis called, that is often.Testing Strategy
This pull request was tested by @alexandruradovici.
TODO or Help Wanted
Feedback
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.