runtime: non-cooperative goroutine preemption #24543
Comments
|
Change https://golang.org/cl/102600 mentions this issue: |
|
Change https://golang.org/cl/102603 mentions this issue: |
|
Change https://golang.org/cl/102604 mentions this issue: |
|
Forwarding some questions from @hyangah on the CL:
All of cgo is currently considered a safe-point (one of the reasons it's relatively expensive to enter and exit cgo) and this won't change.
I don't think the runtime can avoid sending signals to threads that may be in cgo without expensive synchronization on common paths, but I don't think it matters. When it enters the runtime signal handler it can recognize that it was in cgo and do the appropriate thing (which will probably be to just ignore it, or maybe queue up an action like stack scanning).
It should be okay if cgo code uses the signal, as long as it's correctly chained. I'm hoping to use POSIX real-time signals on systems where they're available, so the runtime will attempt to find one that's unused (which is usually all of them anyway), though that isn't an option on Darwin. And a question from @randall77 (which I answered on the CL, but should have answered here):
There's really no cost to the current technique and we'll continue to rely on it in the runtime for the foreseeable future, so my current plan is to leave it in. However, we could be much more aggressive about removing stack bounds checks (for example if we can prove that a whole call tree will fit in the nosplit zone). |
|
So it is still possible to make goroutine nonpreemptable with something like: |
|
Yes, that would still make a goroutine non-preemptible. However, with some extra annotations in the assembly to indicate registers containing pointers it will become preemptible without any extra work or run-time overhead to reach an explicit safe-point. In the case of I'll add a paragraph to the design doc about this. |
|
will the design doc be posted here? |
|
The design doc is under review here: https://golang.org/cl/102600
(As a reminder, please only post editing comments to the CL itself and keep technical discussion on the GitHub issue.)
|
For golang/go#24543. Change-Id: Iba313a963aafcd93521bb9e006cb32d1f242301b Reviewed-on: https://go-review.googlesource.com/102600 Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
|
The doc is now submitted: Proposal: Non-cooperative goroutine preemption |
|
Disclaimer: I'm not a platform expert, or an expert on language implementations, or involved with go aside from having written a few toy programs in it. That said: There's a (potentially) fatal flaw here: As some old notes for SBCL point out, Windows has no working version of preemptive signals without loading a kernel driver, which is generally prohibitive for applications. |
|
I think the example code to avoid creating a past-the-end pointer has a problem if the slice has a capacity of 0. You need to declare _p after the first if statement. |
|
@mtstickney looks like it's true but we can look for other implementations, how they go about the same problem. CoreCLR talks about the same problem - they need to preempt threads for GC and talk about the same bugs with wrong thread context. And they also talk about how they solve it without ditching I'm not an expert in this kind of stuff so I'm sorry if this has nothing to do with solving the problem here. |
|
@creker Nor me, so we're in the same boat there. I hadn't seen the CoreCLR reference before, but that's the same idea as the lisp approach: The trick is capturing the original register set: you can either do it with an OS primitive ( It looks like on some Windows versions, some of the time, you can detect and avoid the race conditions with |
|
Thanks for the pointers about For GC preemption, we can always resume the same goroutine on the same thread after preemption, so there's no need to call For scheduler preemption, things are a bit more complicated, but I think still okay. In this case we would need to call |
|
Change https://golang.org/cl/108497 mentions this issue: |
|
Change https://golang.org/cl/108496 mentions this issue: |
|
Change https://golang.org/cl/108498 mentions this issue: |
Currently, each architecture lowers OpConvert to an arch-specific OpXXXconvert. This is silly because OpConvert means the same thing on all architectures and is logically a no-op that exists only to keep track of conversions to and from unsafe.Pointer. Furthermore, lowering it makes it harder to recognize in other analyses, particularly liveness analysis. This CL eliminates the lowering of OpConvert, leaving it as the generic op until code generation time. The main complexity here is that we still need to register-allocate OpConvert operations. Currently, each arch's lowered OpConvert specifies all GP registers in its register mask. Ideally, OpConvert wouldn't affect value homing at all, and we could just copy the home of OpConvert's source, but this can potentially home an OpConvert in a LocalSlot, which neither regalloc nor stackalloc expect. Rather than try to disentangle this assumption from regalloc and stackalloc, we continue to register-allocate OpConvert, but teach regalloc that OpConvert can be allocated to any allocatable GP register. For #24543. Change-Id: I795a6aee5fd94d4444a7bafac3838a400c9f7bb6 Reviewed-on: https://go-review.googlesource.com/108496 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
These will appear when tracking live pointers in registers, so we need to know whether they have pointers. For #24543. Change-Id: I2edccee39ca989473db4b3e7875ff166808ac141 Reviewed-on: https://go-review.googlesource.com/108497 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: David Chase <drchase@google.com>
Currently Liveness.compact rewrites the Liveness.livevars slice in place. However, we're about to add register maps, which we'll want to track in livevars, but compact independently from the stack maps. Hence, this CL modifies Liveness.compact to consume Liveness.livevars and produce a new slice of deduplicated stack maps. This is somewhat clearer anyway because it avoids potential confusion over how Liveness.livevars is indexed. Passes toolstash -cmp. For #24543. Change-Id: I7093fbc71143f8a29e677aa30c96e501f953ca2b Reviewed-on: https://go-review.googlesource.com/108498 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
|
Change https://golang.org/cl/109351 mentions this issue: |
|
Change https://golang.org/cl/109353 mentions this issue: |
|
Change https://golang.org/cl/213837 mentions this issue: |
On Windows, we implement asynchronous preemption using SuspendThread to suspend other threads in our process. However, SuspendThread is itself actually asynchronous (it enqueues a kernel "asynchronous procedure call" and returns). Unfortunately, Windows' ExitProcess API kills all threads except the calling one and then runs APCs. As a result, if SuspendThread and ExitProcess are called simultaneously, the exiting thread can be suspended and the suspending thread can be exited, leaving behind a ghost process consisting of a single thread that's suspended. We've already protected against the runtime's own calls to ExitProcess, but if Go code calls external code, there's nothing stopping that code from calling ExitProcess. For example, in #35775, our own call to racefini leads to C code calling ExitProcess and occasionally causing a deadlock. This CL fixes this by introducing synchronization between calling external code on Windows and preemption. It adds an atomic field to the M that participates in a simple CAS-based synchronization protocol to prevent suspending a thread running external code. We use this to protect cgocall (which is used for both cgo calls and system calls on Windows) and racefini. Tested by running the flag package's TestParse test compiled in race mode in a loop. Before this change, this would reliably deadlock after a few minutes. Fixes #35775. Updates #10958, #24543. Change-Id: I50d847abcdc2688b4f71eee6a75eca0f2fee892c Reviewed-on: https://go-review.googlesource.com/c/go/+/213837 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
|
List of todo items posted in #36365 |
|
Is there a reason to leave this issue open, given the existence of #36365? |
|
Nope! Closing. |
|
Is there any way to disable preemption altogether? In most situation I want a simple single-threaded asynchronous model similar to node.js, where locks are mostly not needed. Now even if I specify runtime.GOMAXPROCS(1), I have to protect against things like |
|
@szmcdull have you tried this runtime switch? Note that Go had preemption before 1.14... |
Yes I tried. But still got |
|
I think you were just lucky that you didn't see that before 1.14 :-) Try https://golang.org/pkg/sync/#Map For further Q's, I refer you to golang-nuts. You'll get more & faster responses there, generally. |
The user notifier feature allows for filtering of seccomp notifications in userspace. While the user notifier is handling the syscall, the notifying process can be preempted, thus ending the notification. This has become a growing problem, as Golang has adopted signal based async preemption[1]. In this, it will preempt every 10ms, thus leaving the supervisor less than 10ms to respond to a given notification. If the syscall require I/O (mount, connect) on behalf of the process, it can easily take 10ms. This allows the supervisor to set a flag that moves the process into a state where it is only killable by terminating signals as opposed to all signals. Signed-off-by: Sargun Dhillon <sargun@sargun.me> [1]: golang/go#24543
The user notifier feature allows for filtering of seccomp notifications in userspace. While the user notifier is handling the syscall, the notifying process can be preempted, thus ending the notification. This has become a growing problem, as Golang has adopted signal based async preemption[1]. In this, it will preempt every 10ms, thus leaving the supervisor less than 10ms to respond to a given notification. If the syscall require I/O (mount, connect) on behalf of the process, it can easily take 10ms. This allows the supervisor to set a flag that moves the process into a state where it is only killable by terminating signals as opposed to all signals. The process can still be terminated before the supervisor receives the notification. Signed-off-by: Sargun Dhillon <sargun@sargun.me> [1]: golang/go#24543
The user notifier feature allows for filtering of seccomp notifications in userspace. While the user notifier is handling the syscall, the notifying process can be preempted, thus ending the notification. This has become a growing problem, as Golang has adopted signal based async preemption[1]. In this, it will preempt every 10ms, thus leaving the supervisor less than 10ms to respond to a given notification. If the syscall require I/O (mount, connect) on behalf of the process, it can easily take 10ms. This allows the supervisor to set a flag that moves the process into a state where it is only killable by terminating signals as opposed to all signals. The process can still be terminated before the supervisor receives the notification. Signed-off-by: Sargun Dhillon <sargun@sargun.me> [1]: golang/go#24543
The user notifier feature allows for filtering of seccomp notifications in userspace. While the user notifier is handling the syscall, the notifying process can be preempted, thus ending the notification. This has become a growing problem, as Golang has adopted signal based async preemption[1]. In this, it will preempt every 10ms, thus leaving the supervisor less than 10ms to respond to a given notification. If the syscall require I/O (mount, connect) on behalf of the process, it can easily take 10ms. This allows the supervisor to set a flag that moves the process into a state where it is only killable by terminating signals as opposed to all signals. The process can still be terminated before the supervisor receives the notification. Signed-off-by: Sargun Dhillon <sargun@sargun.me> [1]: golang/go#24543
The user notifier feature allows for filtering of seccomp notifications in userspace. While the user notifier is handling the syscall, the notifying process can be preempted, thus ending the notification. This has become a growing problem, as Golang has adopted signal based async preemption[1]. In this, it will preempt every 10ms, thus leaving the supervisor less than 10ms to respond to a given notification. If the syscall require I/O (mount, connect) on behalf of the process, it can easily take 10ms. This allows the supervisor to set a flag that moves the process into a state where it is only killable by terminating signals as opposed to all signals. The process can still be terminated before the supervisor receives the notification. Signed-off-by: Sargun Dhillon <sargun@sargun.me> [1]: golang/go#24543
and others
I propose that we solve #10958 (preemption of tight loops) using non-cooperative preemption techniques. I have a detailed design proposal, which I will post shortly. This issue will track this specific implementation approach, as opposed to the general problem.
Edit: Design doc
Currently, Go currently uses compiler-inserted cooperative preemption points in function prologues. The majority of the time, this is good enough to allow Go developers to ignore preemption and focus on writing clear parallel code, but it has sharp edges that we've seen degrade the developer experience time and time again. When it goes wrong, it goes spectacularly wrong, leading to mysterious system-wide latency issues (#17831, #19241) and sometimes complete freezes (#543, #12553, #13546, #14561, #15442, #17174, #20793, #21053). And because this is a language implementation issue that exists outside of Go's language semantics, these failures are surprising and very difficult to debug.
@dr2chase has put significant effort into prototyping cooperative preemption points in loops, which is one way to solve this problem. However, even sophisticated approaches to this led to unacceptable slow-downs in tight loops (where slow-downs are generally least acceptable).
I propose that the Go implementation switch to non-cooperative preemption using stack and register maps at (essentially) every instruction. This would allow goroutines to be preempted without explicit
preemption checks. This approach will solve the problem of delayed preemption with zero run-time overhead and have side benefits for debugger function calls (#21678).
I've already prototyped significant components of this solution, including constructing register maps and recording stack and register maps at every instruction and so far the results are quite promising.
/cc @drchase @RLH @randall77 @minux
The text was updated successfully, but these errors were encountered: