You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In an ideal world, we should first place this thread poorly, ask for more cores, and re-place it when more cores become available.
When a core arrives, reconsider everything. Ask Arachne to tell you about all the threads that have a particular class. Then we find all the ones that are marked exclusive and see "are they in fact exclusive?"
If not, then fix it.
This mechanism should fix other races with incorrectly placed threads.
The text was updated successfully, but these errors were encountered:
hq6
changed the title
More gracefully handle requests for exclusive cores when none are available
More gracefully handle requests for exclusive cores when there are fewer cores than exclusive cores requested.
Mar 28, 2018
One possibility: Block until an exclusive core can be made available through the arbiter, with some timeout (maybe arbiter preemption timeout)
Another possibility: Put it on the unmanaged core as a kernel thread until a core is available.
Arachne would have to create extra kernel threads which run unmanaged.
CorePolicy doesn't know the ThreadIds?
When a new core joins the policy, you'd have to search the unmanaged kernel threads and move Arachne threads to cores.
Even if we don't get exclusive cores, they can still make progress.
You cannot create more exclusive threads than cores available; other mechanisms add a lot of complexity.
Load estimator needs resources. Need at least one non-exclusive core.
Ensure that Arachne does not yield cores beyond minNumCores, even if mustReleaseCore returns true.
John's suggestion:
The text was updated successfully, but these errors were encountered: