runtime: NUMA optimization for channels #12298
Labels
Comments
|
A slice is just a pointer, basically. See http://blog.golang.org/go-slices-usage-and-internals The scheduler continues to improve, and data locality is definitely a part of that. I don't think there's anything specifically actionable here. |
|
I edited it to a struct after I opened the bug. |
|
Structs are relocated to the target NUMA node, in particular they are copied to the target's stack frame. |
|
For slices, I think we need a moving GC to br able to support this kind of
NUMA migration (the runtime need to preserve the shared memory semantics,
so it needs to handle the case where the sender still holds a reference to
the underlying array.)
|
mikioh
changed the title
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is a big job. This is an optimization of the sharing memory by communicating method.[1]
When a struct (not a pointer) above a GO_NUMA_MIGRATE size (determined at compile time) is sent across a channel the slice should be relocated to run on a local NUMA node.
[1] http://blog.golang.org/share-memory-by-communicating
The text was updated successfully, but these errors were encountered: