Am 21.05.2021 um 22:24 schrieb John Kacur:
On Tue, 18 May 2021, Jonathan Schwender wrote:
This allows the user to specify a separate cpuset for the main pid,
e.g. on a housekeeping CPU.
If --mainaffinity is not specified, but --affinity is, then the
current behaviour is preserved and the main thread is bound
to the cpuset specified by --affinity
@@ -1802,7 +1816,9 @@ int main(int argc, char **argv)
}
/* Restrict the main pid to the affinity specified by the user */
- if (affinity_mask != NULL) {
+ if (main_affinity_mask != NULL) {
+ set_main_thread_affinity(main_affinity_mask);
Am I missing something here, if there is a main_affinity_mask we set that
but then skip over the affinity_mask. Don't we want to check both?
So the idea here is that if --mainaffinity is specified, then we set the
affinity of the main thread
to the specified value, _regardless_ of --affinity. E.g.:
cyclictest --affinity=1,2,3 --mainaffinity=0 [other options]
The intended behavior is that the main thread is bound to CPU 0, and the
other threads to CPUs 1-3.
I don't see a reason why mainaffinity should be restricted to a subset
of affinity. E.g., if for some reason
(e.g. cyclictest in a container) you spawn multiple cyclictest instances
with non-overlapping affinity cpusets
but want to offload the main pids to a common CPU (e.g. CPU 0).
Restricting mainaffinity to a subset of
affinity would mean that now every cyclictest instance also must spawn a
measurement thread on CPU 0,
even if you aren't really interested in the latencies of the
housekeeping CPU. Due to the (potentially) high priority of
the timer threads, they might even negatively influence isolated CPUs by
delaying offloaded tasks.
Another way to look at it is that --mainaffinity (if present) overrides
--affinity when determining the target affinity for the
main thread. The affinity for the measurement threads is not affected by
this in any way.
+ } else if (affinity_mask != NULL) {
set_main_thread_affinity(affinity_mask);
if (verbose)
printf("Using %u cpus.\n",
--
2.31.1
