On 1/6/24 03:16, Martin Husemann wrote:
On Fri, Jan 05, 2024 at 03:20:34PM -0600, Jason Bacon wrote:Some good points have been made about the complexity of the issue, but after giving it some though, I don't see any down side to simply exposing the physical core count. More complex cases like asymmetric CPU packages will require more information in order to optimize jobs fully, but I think that's a separate issue.We should expose all the data the kernel has for this, and if userland wants to condense that data into a single number, userland can do the math. Currently the kernel knows (for each attached cpu): - node # - package # - core # - smt # - cpu class (currently restricted to slow/fast but needs to be extended) A MI sysctl returning that for each cpu would be a good start. Martin
I like this approach. By "attached cpu", do you mean all everything counted by hw.ncpu? So then computing a physical core count would involve looping through all attached cpus looking for smt # = 0? As for improving on slow/fast, FreeBSD exposes all available clock frequencies along with the currently used one: FreeBSD coral.acadix bacon ~ 1018: sysctl dev.cpu | grep freq | sort dev.cpu.0.freq: 2901 dev.cpu.0.freq_levels: 2901/35000 2900/35000 2800/33218 2700/31812 2600/30093 2500/28743 2400/27087 2300/25796 2200/24202 2100/22958 2000/21425 1900/20234 1800/19072 1700/17625 1600/16509 dev.cpu.1.freq: 2901 dev.cpu.1.freq_levels: 2901/35000 2900/35000 2800/33218 2700/31812 2600/30093 2500/28743 2400/27087 2300/25796 2200/24202 2100/22958 2000/21425 1900/20234 1800/19072 1700/17625 1600/16509 dev.cpu.2.freq: 2901 dev.cpu.2.freq_levels: 2901/35000 2900/35000 2800/33218 2700/31812 2600/30093 2500/28743 2400/27087 2300/25796 2200/24202 2100/22958 2000/21425 1900/20234 1800/19072 1700/17625 1600/16509 dev.cpu.3.freq: 2901 dev.cpu.3.freq_levels: 2901/35000 2900/35000 2800/33218 2700/31812 2600/30093 2500/28743 2400/27087 2300/25796 2200/24202 2100/22958 2000/21425 1900/20234 1800/19072 1700/17625 1600/16509