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.

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

Scheduler flag to enable dispatch from scheduler thread *with* pending events #415

Open
gparmer opened this issue Mar 16, 2021 · 0 comments

Comments

@gparmer
Copy link
Collaborator

gparmer commented Mar 16, 2021

Background

The kernel maintains a list of asynchronous events to be delivered to the (core's) scheduler thread. These include the activation of threads through asnds from interrupts, the preemption of threads when those asnds activate a thread, and the consumption of time through execution of interrupt threads. In short, all of the events that bypass the scheduler (asynchronous activations) are tracked this way.

To compensate for race conditions, if a dispatch is ever attempted, and the scheduler thread has pending events, we switch to the scheduler thread so that it can clear them out, thus making a more accurate scheduling decision. However, an annoying edge case is this: If the scheduler thread knows that there are events to process, and tries to take the scheduler critical section, and another thread is already in the critical section, then the scheduler thread cannot switch to that thread (given the logic from the previous paragraph). Thus, we're stuck: we cannot process the events as we cannot take the critical section.

The current code simply loops removing all scheduler events adding them to a linked list, then once they are all processed, it will attempt to take the critical section, and apply the side effects of the events (i.e. wake/block threads).

Problems

The problems with the above approach:

  1. We wish to maintain TCap inheritance during scheduler thread execution. But we cannot track that when the events aren't pending. This is a "light" requirement, as using only the core TCap's priority should be correct as it should have highest priority.
  2. Requiring the doubly linked list in the scheduler core is going to make verification very hard.
  3. We are delaying applying the effects of the events.

The big upside of this approach is that the event retrieval is completely outside of the critical section. From a worst-case perspective, I don't think this matters much as a high-priority thread has to wait for the CS regardless.

Proposal

Add a flag to thread dispatch that only the scheduler thread can pass that enables a dispatch even if there are pending scheduler events. This flag should only be used in the case that the scheduler thread is switching to a thread that has the scheduler CS, thus it will be re-activated to process the events ASAP. This removes the linked list at user-level, and simplifies the scheduler loop while adding very little complication to the kernel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant