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 upruntime: "program exceeds 50-thread limit" in test of os package on darwin-arm-mg912baios [1.13 backport] #34712
Labels
Milestone
Comments
This comment has been minimized.
This comment has been minimized.
|
@minux Backporting approved. Please prepare a cherry-pick CL as per https://github.com/golang/go/wiki/MinorReleases. |
This was referenced Oct 9, 2019
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/200103 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/200105 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
|
Closed by merging 81d995d to release-branch.go1.13. |
gopherbot
pushed a commit
that referenced
this issue
Oct 9, 2019
…ssion While understanding why syscall.Read is 2x slower on darwin/amd64, I found out that, contrary to popular belief, the slowdown is not due to the migration to use libSystem.dylib instead of direct SYSCALLs, i.e., CL 141639 (and #17490), but due to a subtle change introduced in CL 141639. Previously, syscall.Read used syscall.Syscall(SYS_READ), whose preamble called runtime.entersyscall, but after CL 141639, syscall.Read changes to call runtime.syscall_syscall instead, which in turn calls runtime.entersyscallblock instead of runtime.entersyscall. And the entire 2x slow down can be attributed to this change. I think this is unnecessary as even though syscalls like Read might block, it does not always block, so there is no need to handoff P proactively for each Read. Additionally, we have been fine with not handing off P for each Read prior to Go 1.12, so we probably don't need to change it. This changes restores the pre-Go 1.12 behavior, where syscall preamble uses runtime.entersyscall, and we rely on sysmon to take P back from g blocked in syscalls. Updates #34712 Change-Id: If76e97b5a7040cf1c10380a567c4f5baec3121ba Reviewed-on: https://go-review.googlesource.com/c/go/+/197938 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> (cherry picked from commit c1635ad) Reviewed-on: https://go-review.googlesource.com/c/go/+/200103 Run-TryBot: Alexander Rakoczy <alex@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
gopherbot
pushed a commit
that referenced
this issue
Oct 9, 2019
CL 197938 actually fixes those regression on Darwin as syscalls are no longer labeled as always blocking and consume a thread. Fixes #34712 Change-Id: I82c98516c23cd36f762bc5433d7b71ea8939a0ac Reviewed-on: https://go-review.googlesource.com/c/go/+/199477 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> (cherry picked from commit cfe2320) Reviewed-on: https://go-review.googlesource.com/c/go/+/200105 Run-TryBot: Alexander Rakoczy <alex@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@odeke-em requested issue #32326 to be considered for backport to the next 1.13 minor release.