There was (and maybe still based on open github issues) an issue with CFS where CPU throttling would occur in some unexpected ways. I realize this original reference is a little different than it currently works after a couple rounds of fixing that has been done in the kernel. https://engineering.indeedblog.com/blog/2019/12/unthrottled-fixing-cpu-limits-in-the-cloud/ https://engineering.indeedblog.com/blog/2019/12/cpu-throttling-regression-fix/
My understanding is that the CFS allocates a certain proportion of a given time slice to processes when using CFS qoutas.
- If I have a small enough.NET Core continuation (as in the boundaries in an async task between awaits) does that continuation end up running within a single "time slice"?
- If it is a small (.NET Core) continuation that is very short such that the entire time slice isn't needed, does it end up returning the slack quota back to the global bucket?
- Can multiple parallel continuations interleave in the time slice?
- When using a container is it treated as a singular process from the perspective of the CFS on the host or is there first class visibility into the threading inside the container?
The core intuition I am trying to establish is if it is accurate to consider that small async tasks may end up causing more overhead in returns to the global bucket inside the CFS; or if there is little relationship at that level between CFS throttling behaviors and .NET Core async usage. I am considering this from the perspective of an environment using Kubernetes.
From this I'm wondering if CFS optimal tuning is directly correlated with async/await usage, or if after miscellaneous nuance, abstraction through containers and the.NET CLR it's not really related.
