FreeBSD: Improve CPU core count handling

[etcwilde]

This improves the CPU core count handling for FreeBSD. This uses sysconf to grab the number of configured processors when logical and physical CPU counts are requested, and then pthread_getaffinity_np and the number of active processors. This takes into account the number of available cores when the process is restricted to a subset of the processors.

This also fixes the dispatch_workqueye test, which has its own implementation to extract the core count. FreeBSD does not have an hw.activecpu syscall, so the syscallbyname was failing and the activecpu count was garbage from the stack. I've updated the test to initialize the value with 0xa1a1a1 to make the garbage clearer. Also update the test for FreeBSD to take advantage of sysconf and pthread_getaffinity_np in the test.

Fixes: #897

[etcwilde]

CC @kevans91

[etcwilde]

@swift-ci please test

[kevans91]

This looks reasonable, thanks!

[etcwilde]

@swift-ci please test

[kevans91]

LGTM, for what that's worth. Happy to look a little bit closer if there's still something off with the test (I haven't tried to run it yet, personally).

[etcwilde]

Thanks for your help. I’ve checked on my FreeBSD box, and all tests are passing with this change.

[etcwilde]

@swift-ci please test Windows

[al45tair]

I'm assuming FreeBSD doesn't have anything like the problem Linux has with cgroups (namely, on Linux you can use cgroups to restrict the number of CPU cores available, but the usual ways of querying CPU core availability still report the number of cores on the system, not the number of cores set in the cgroup).

[kevans91]

I'm assuming FreeBSD doesn't have anything like the problem Linux has with cgroups (namely, on Linux you can use cgroups to restrict the number of CPU cores available, but the usual ways of querying CPU core availability still report the number of cores on the system, not the number of cores set in the cgroup).

As in: sched_getaffinity/pthread_getafffinity_np won't report these restrictions either and you need cgroup-specific bits, or this is the reason for checking the affinity?

You can cpuset(8) away CPUs entirely per-process or per-jail without visibility to sysconf(3) or via a sysctl. If it's done at the jail level you're pretty much restricted to that subset, if it's per-process you have a chance of lifting the restriction.

It would be true on FreeBSD to say that the current implementation of _dispatch_hw_config_logical_cpus and _dispatch_hw_config_physical_cpus may be inaccurate if you're in a jail that has a more limited root set because you wouldn't be able to cpuset_setaffinity(2) your way up to the currently reported values -- you would need to grab your root cpuset id and check the affinity of that to understand the most a process has available to it beyond what's currently configured.

I don't think it's a problem that FreeBSD couldn't fix, but it is a little awkward to do so.