Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: high-percentile latency of memory allocations has regressed significantly [1.13 backport] #34556
For some reason gopherbot wouldn't open a backport issue for me. This is a backport of #31678.
The fixes for this (once and for all) have landed in master. https://go-review.googlesource.com/c/go/+/183857/9
The importance of this bug for a 1.13 backport is the fact that it's one of the pieces to the fix for #32828 for Go 1.13, which is a major regression in Kubernetes which is blocking them from landing.
There are two problems with Kubernetes: inline scavenging on the allocation path can really spike allocation tail latencies (this issue) and it could spiral into over-scavenging if fragmentation is not accounted for (#34149).
The fixes for both issues must be landed together to completely fix the issue.
I agree that we should backport this fix. This and #34149 are blocking k8s from upgrading to Go 1.13.
To be clear, the following two CLs need to be backported for this:
CL 183857 is nearly identical to a change we backported to Go 1.12. CL 189957 is necessary for CL 183857 to be most effective.
Currently, we map and grow the heap a whole arena (64MB) at a time. Unfortunately, in order to fix #32828, we need to switch from scavenging inline with allocation back to scavenging on heap growth, but heap-growth scavenging happens in large jumps because we grow the heap in large jumps. In order to prepare for better heap-growth scavenging, this CL separates mapping more space for the heap from actually "growing" it (tracking the new space with spans). Instead, growing the heap keeps track of the "current arena" it's growing into. It track that with new spans as needed, and only maps more arena space when the current arena is inadequate. The effect to the user is the same, but this will let us scavenge on much smaller increments of heap growth. There are two slightly subtleties to this change: 1. If an allocation requires mapping a new arena and that new arena isn't contiguous with the current arena, we don't want to lose the unused space in the current arena, so we have to immediately track that with a span. 2. The mapped space must be accounted as released and idle, even though it isn't actually tracked in a span. For #32828, since this makes heap-growth scavenging far more effective, especially at small heap sizes. For example, this change is necessary for TestPhysicalMemoryUtilization to pass once we remove inline scavenging. Updates #34556 Change-Id: I300e74a0534062467e4ce91cdc3508e5ef9aa73a Reviewed-on: https://go-review.googlesource.com/c/go/+/189957 Run-TryBot: Austin Clements <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Keith Randall <firstname.lastname@example.org> Reviewed-by: Michael Knyszek <email@example.com> (cherry picked from commit f18109d) Reviewed-on: https://go-review.googlesource.com/c/go/+/198485 Run-TryBot: Andrew Bonventre <firstname.lastname@example.org> Reviewed-by: Austin Clements <email@example.com>
… with allocation Inline scavenging causes significant performance regressions in tail latency for k8s and has relatively little benefit for RSS footprint. We disabled inline scavenging in Go 1.12.5 (CL 174102) as well, but we thought other changes in Go 1.13 had mitigated the issues with inline scavenging. Apparently we were wrong. This CL switches back to only doing foreground scavenging on heap growth, rather than doing it when allocation tries to allocate from scavenged space. Fixes #34556 Change-Id: I1f5df44046091f0b4f89fec73c2cde98bf9448cb Reviewed-on: https://go-review.googlesource.com/c/go/+/183857 Run-TryBot: Austin Clements <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Keith Randall <firstname.lastname@example.org> Reviewed-by: Michael Knyszek <email@example.com> (cherry picked from commit eb96f8a) Reviewed-on: https://go-review.googlesource.com/c/go/+/198486 Reviewed-by: Austin Clements <firstname.lastname@example.org> Run-TryBot: Andrew Bonventre <email@example.com>