Support changes in the number of cpus given by cpu.Counts

[danielnelson]

Is your feature request related to a problem? Please describe.

In Telegraf, it has been suggested that we report changes to the number of cpus without restarting the process. In KVM, and many other hypervisors the number of cpus can be hotplugged on a running VM.

Currently we are calling runtime.NumCPU() in Telegraf directly, but I would like to move this to use cpu.Counts. However, the implementation on Linux is the same runtime.NumCPU() call.

Describe the solution you'd like

Instead of using the cached number of CPU from Go, each call to cpu.Counts() should attempt to discover the number of CPUs again.

Describe alternatives you've considered

None

Additional context

influxdata/telegraf#5451

[Lomanic]

As raised in #628 we should have OS-specific functions to gather the number of cores, runtime.NumCPU() is not sufficient (it returns the number available cores for the process, which can change afterwards on VMs indeed and we can't distinguish between logical and physical cores).

[mznet]

@Lomanic Refer to the document about runtime.NumCPU(), this method shows only the number of CPUs at process startup and can't reflect the changes after startup. To reflect the change of CPU properly, we should not use runtime.NumCPU so that need to find an alternative way, IMHO.
What about using SC_NPROCESSORS_ONLN or /proc/cpuinfo to get the number of logical or physical CPUs like original psutil implementation

Update: I didn't consider that those two ways are only available on linux. I take it back.

[danielnelson]

What do you think about just pulling up the implementations from Go without the caching? Every platform would of course need a different implementation.

[Lomanic]

I think we shouldn't reuse runtime.NumCPU code with caching removed, we will still have to port psutil code to implement logical/physical cores count (the logical argument) afterwards.

Also almost all the platforms implement processor affinity (how many cores the process can run on) in runtime.NumCPU, which is not exactly the number of physical or logical cores on the machine. Plus I'm not even sure it gets updated after process startup and at least one implementation relies on assembly.