> Basically, your particular runtime system is probably not going to be the only thing running on a host.
I'm running Erlang, not Go, but basically the runtime is the only real thing running on our systems[1], so it's good for the runtime to pin its os-threads to specific logical processors. On the systems where this isn't the case (for example, when using a separate TLS termination daemon), it's easy to unpin the threads and let the OS manage where to run things.
[1] there's also monitoring, ntpd, sshd, getty, and network/disk processing in the kernel
I'm unfamiliar with Erlang's runtime, so please forgive some basic questions.
Is Erlang's runtime doing the thread pinning without any input from you? Or are you, at the application level, explicitly telling the Erlang runtime how to pin threads?
edit: Did some googling, looks like it's the latter: http://erlang.org/doc/man/erl.html#+sbt. There are a bunch of policy options where the user picks what behavior they think will work best with their application, on the current system. Key to my point, though is: The runtime system will by default not bind schedulers to logical processors.
Providing options where users opt-in to such behavior is good. But the Go proposal, as far as I read, was unilaterally proposing that is how the runtime would work, always. That's not good, for the reasons I stated.
Erlang/Go/Java VMs could probably benefit from some kind of "appliance mode" where they take over the whole machine and reconfigure the kernel for maximum performance, but I wouldn't want that mode to be the default.
I'm running Erlang, not Go, but basically the runtime is the only real thing running on our systems[1], so it's good for the runtime to pin its os-threads to specific logical processors. On the systems where this isn't the case (for example, when using a separate TLS termination daemon), it's easy to unpin the threads and let the OS manage where to run things.
[1] there's also monitoring, ntpd, sshd, getty, and network/disk processing in the kernel