When hw.smt is enabled, and it's enabled by default from 6.4, the
number of cpus given by `runtime.NumCPU()` is half of the total: only
the cpuN with N = 0,2,4,... are used by the system. We need to detect
that and ask for the correct stats.
Fix: get cptime of n-th cpu when `percpu` instead of the average.
While there, rearrange the last if statement to make the code a bit
more homogeneous.
Empirical benchmark (calling to cpu.Info):
Lomanics-iMac:~ lomanic$ time ./cpu_info
info 0: {"cpu":0,"vendorId":"GenuineIntel","family":"6","model":"30","stepping":5,"physicalId":"","coreId":"","cores":2,"modelName":"Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz","mhz":2590,"cacheSize":256,"flags":["syscall","xd","em64t","lahf","lzcnt","prefetchw","rdtscp","tsci","fpu","vme","de","pse","tsc","msr","pae","mce","cx8","apic","sep","mtrr","pge","mca","cmov","pat","pse36","clfsh","mmx","fxsr","sse","sse2","htt","sse3","ssse3","cx16","sse4.1","sse4.2","popcnt","vmm"],"microcode":""}
real 0m0.049s
user 0m0.023s
sys 0m0.041s
Lomanics-iMac:~ lomanic$ time ./cpu_info.fixed
info 0: {"cpu":0,"vendorId":"GenuineIntel","family":"6","model":"30","stepping":5,"physicalId":"","coreId":"","cores":2,"modelName":"Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz","mhz":2590,"cacheSize":256,"flags":["fpu","vme","de","pse","tsc","msr","pae","mce","cx8","apic","sep","mtrr","pge","mca","cmov","pat","pse36","clfsh","mmx","fxsr","sse","sse2","htt","sse3","ssse3","cx16","sse4.1","sse4.2","popcnt","vmm","syscall","xd","em64t","lahf","lzcnt","prefetchw","rdtscp","tsci"],"microcode":""}
real 0m0.010s
user 0m0.004s
sys 0m0.006s
Fix#551 Filter out '_Total' results from PerfInfoWithContext and unexport this function.
Also propagate context in perCPUTimes (renamed to perCPUTimesWithContext) and unexport Win32_PerfFormattedData_Counters_ProcessorInformation type.
The order of init function execution is dependant on the order that the
source files are passed to the compiler. This causes issues when
building under other build systems, such as bazel or buck, as they are
not guarenteed to maintain the same file order as the default go tool.
In order to improve performance and help prevent crashes due to the outstanding fork crash bug:
https://github.com/golang/go/issues/15658
Replace string parsed values from the sysctl command with native reads of sysctl values using unix.SysctlRaw and unix.SysctlUint32.
This also merges OpenBSD and FreeBSD load implementations which are identical.
This commit adds Solaris(^1) support for the Info() function of package
cpu, with the exception of the L2 cache size which is not trivially
available(^2).
Support is implemented by parsing the output of `isainfo -b -v` (for the
instruction set flags), and `psr-info -p -v` for other information.
Example outputs from a range of different size VMs and Joyent containers
are included as part of the tests.
(^1): This has only been tested with Illumos in the form of SmartOS. I
believe it to be portable to other Illumos distributions but have not
tested on Oracle Solaris.
(^2): Enough support is added here to be usable for my port of
HashiCorp's Nomad to SmartOS.
Currently gopsutils fails to indentify the POWER processors family,
returning an almost empty Info() structure.
This patch improves the POWER identification without changing what is
available for x86.
* on virtualized host, this may happen.
* but we may have a value from parsing `/proc/cpuinfo`
* in this case, we do not return the error if we fail to extra
a value from `cpufreq/cpuinfo_max_freq`
* resolve#249
* in `cpu_windows.go`, `Mhz` is the value of `MaxClockSpeed`
* on Linux platform, the `Mhz` value is extracted from `/proc/cpuinfo`
which reflects the current clock speed; treat this as the fallback
value instead
* read from `cpufreq/cpuinfo_max_freq` under sysfs to get the
maximum clock speed for `Mhz`, just like for Windows platform
* also fix the path to `cpu.CoreID` value; the filename is `core_id`
* for Darwin, it is a minor tweak for readability: the value
returned is in Hz, so using a variable named 'hz' makes more
sense than 'mhz'
* for Linux, the unit is in kHz so we need to divide the value
from `cpuinfo_max_freq` by 10^3 to get MHz (see
cpu-freq/user-guide.txt of the kernel documentation)
This enables using gopsutil in a codebase that gets built on other OSes
than the ones supported. Instead of a build failure as before, due to
the build tags, gopsutil will now throw an "not implemented" runtime
error.
Fixes#234.
renaynay