Are there any proposals to make the golang runtime cgroup aware? Last time I checked the go runtime will spawn a OS process for each cpu it can see even if it is running in a cgroup which only allows 1 CPU of usage.
On servers with 100+ cores I have seen scheduling time take over 10% of the program runtime.<p>The fix is to inspect the cgroupfs to see how many CPU shares you can utilize and then set gomaxprocs to match that. I think other runtime like Java and .NET do this automatically.<p>It is the same thing with GOMEMLIMIT, I don’t see why the runtime does not inspect cgroupfs and set GOMEMLIMIT to 90% of the cgroup memory limit.
> think about it - what if I suddenly stopped you while taking a dump? It would have been easier to have stopped you before, or after, but not in the middle of it. Not sure about the analogy, but you got it.<p>Gold.
Great post! One question that lingered for me is: what are asynchronous safe-points? The post goes into some detail about their synchronous counterparts
If you'd like to see a really well done deep dive by the new Golang Tech Lead ( Austin Clements), check this out<p>GopherCon 2020: Austin Clements - Pardon the Interruption: Loop Preemption in Go 1.14<p><a href="https://www.youtube.com/watch?v=1I1WmeSjRSw" rel="nofollow">https://www.youtube.com/watch?v=1I1WmeSjRSw</a>
Interesting that it’s temporal (according to the article, you have around 10 microseconds before the signal-based preempter kicks in). How bad is performance if the load on the host is so high that double-preempting is common, I wonder? Or am I missing something and that question is not meaningful?
This is a well-written article, but one thing that wasn't clear to me was how the runtime determines that it's at a safe point. Can someone shed some light on that?