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 working on #36507, I noticed that one source of regression on Darwin was that sysUsed, as of Go 1.14, is now called on the whole memory allocation, even if just one page of that is actually scavenged. This behavior was already present in Go 1.11, went away in Go 1.12, and is now back.
On systems where sysUsed is a no-op and we rely on the first access "unscavenging" the page, this has no effect, because we're already only unscavenging exactly what's needed. On systems like Darwin and Windows where the "recommit" step is explicit (i.e. sysUsed is not a no-op) this can have a non-trivial impact on performance, since the kernel probably walks over the unscavenged pages for nothing.
This contributed very slightly to the performance regression in #36218, but not enough to cause it to block the 1.14 release.
The fix here is straight-forward: we just need to lower the call of sysUsed in the page allocator where we have complete information over exactly which pages are scavenged. If a given allocation has >50% of its pages scavenged then we can probably just sysUsed the whole thing to save a bit on syscall overheads. This change also makes sense because we already do sysUnused at a fairly low-level part of the page allocator, so bringing sysUsed down there makes sense.
The text was updated successfully, but these errors were encountered:
Hello @mknyszek, thank you for reporting this and for the details! Given that we haven't covered much ground for Go1.15 on this issue, is there something else we can do or shall we move it to Go1.16 and then backport fixes to Go1.14 and Go1.15? Thank you.
This isn't essential. Let's move it to 1.16. No need to backport, either, the performance regression here is very slight in practice (even in microbenchmarks that specifically seem to trigger bad behavior here), and other improvements probably totally overcame it in practice. Worth fixing, but not with any urgency.