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
Today, the scheduler is essentially the Go runtime scheduler. In some cases however, this can lead to poor interactions between application threads and extra cycles burnt (e.g. #2033, #1942).
This issue serves as the parent issue for scheduler exploration. There are effectively two possible paths that we will pursue:
Reduce negative interactions with the Go scheduler by binding task goroutines directly to host threads. This may require some modifications to the Go runtime that allow for a larger number of Ps, as many of the poor interactions come at the entersyscall/exitsyscall time (and may involve the sysmon thread). This has advantage that it's likely to map closely to host performance if done correctly. It has the disadvantage that the number of threads is under user control, and the failure to create a new host thread can take place at any point in the runtime (likely taking down the sandbox).
Take more control over interactions with the Go runtime and implement some custom scheduling functionality. This will likely require more work, and it's unclear to the extent we can implement anything reasonably performance. However, this does not suffer from the host thread limit failures discussed in (1).
Today we effectively have some of the worst of both (1) and (2). We should continue to explore the appropriate avenue, come up with a design and improve our scheduler scalability.
The text was updated successfully, but these errors were encountered:
@milantracy I actually don't have extensive experience using gvisor, I'm just curious about the overall details of the documentation and code implementation of the proposed improvement plan.
Today, the scheduler is essentially the Go runtime scheduler. In some cases however, this can lead to poor interactions between application threads and extra cycles burnt (e.g. #2033, #1942).
This issue serves as the parent issue for scheduler exploration. There are effectively two possible paths that we will pursue:
Today we effectively have some of the worst of both (1) and (2). We should continue to explore the appropriate avenue, come up with a design and improve our scheduler scalability.
The text was updated successfully, but these errors were encountered: