| Message ID | 20240206095642.work.502-kees@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | selftests/seccomp: Pin benchmark to single CPU | expand |
On Tue, Feb 06, 2024 at 01:56:47AM -0800, Kees Cook wrote: > + /* Set from highest CPU down. */ > + for (cpu = ncores - 1; cpu >= 0; cpu--) { > + CPU_ZERO_S(setsz, setp); > + CPU_SET_S(cpu, setsz, setp); Is there some particular reason to go from the highest CPU number down? Not that it super matters but the default would be to iterate from 0 and there's a comment but it just says the what not the why.
On Tue, Feb 06, 2024 at 10:16:19AM +0000, Mark Brown wrote: > On Tue, Feb 06, 2024 at 01:56:47AM -0800, Kees Cook wrote: > > > + /* Set from highest CPU down. */ > > + for (cpu = ncores - 1; cpu >= 0; cpu--) { > > + CPU_ZERO_S(setsz, setp); > > + CPU_SET_S(cpu, setsz, setp); > > Is there some particular reason to go from the highest CPU number down? > Not that it super matters but the default would be to iterate from 0 and > there's a comment but it just says the what not the why. I was arbitrarily picking a direction and all the examples I could find started at 0, so this would be more (?) out of the way. :P Without a cpu cgroup, I can't _exclude_ the pinned CPU from other processes, so I was pretending the last CPU will be less likely to be used.
On Tue, Feb 06, 2024 at 03:04:32AM -0800, Kees Cook wrote: > On Tue, Feb 06, 2024 at 10:16:19AM +0000, Mark Brown wrote: > > On Tue, Feb 06, 2024 at 01:56:47AM -0800, Kees Cook wrote: > > > + /* Set from highest CPU down. */ > > > + for (cpu = ncores - 1; cpu >= 0; cpu--) { > > > + CPU_ZERO_S(setsz, setp); > > > + CPU_SET_S(cpu, setsz, setp); > > Is there some particular reason to go from the highest CPU number down? > > Not that it super matters but the default would be to iterate from 0 and > > there's a comment but it just says the what not the why. > I was arbitrarily picking a direction and all the examples I could find > started at 0, so this would be more (?) out of the way. :P > Without a cpu cgroup, I can't _exclude_ the pinned CPU from other > processes, so I was pretending the last CPU will be less likely to be > used. That feels like it should go in a comment so it's a bit less mysterious.
diff --git a/tools/testing/selftests/seccomp/seccomp_benchmark.c b/tools/testing/selftests/seccomp/seccomp_benchmark.c index 5b5c9d558dee..d0b733e708cc 100644 --- a/tools/testing/selftests/seccomp/seccomp_benchmark.c +++ b/tools/testing/selftests/seccomp/seccomp_benchmark.c @@ -4,7 +4,9 @@ */ #define _GNU_SOURCE #include <assert.h> +#include <err.h> #include <limits.h> +#include <sched.h> #include <stdbool.h> #include <stddef.h> #include <stdio.h> @@ -119,6 +121,29 @@ long compare(const char *name_one, const char *name_eval, const char *name_two, return good ? 0 : 1; } +/* Pin to a single CPU so the benchmark won't bounce around the system. */ +void affinity(void) +{ + long cpu; + ulong ncores = sysconf(_SC_NPROCESSORS_CONF); + cpu_set_t *setp = CPU_ALLOC(ncores); + ulong setsz = CPU_ALLOC_SIZE(ncores); + + /* Set from highest CPU down. */ + for (cpu = ncores - 1; cpu >= 0; cpu--) { + CPU_ZERO_S(setsz, setp); + CPU_SET_S(cpu, setsz, setp); + if (sched_setaffinity(getpid(), setsz, setp) == -1) + continue; + printf("Pinned to CPU %lu of %lu\n", cpu + 1, ncores); + goto out; + } + fprintf(stderr, "Could not set CPU affinity -- calibration may not work well"); + +out: + CPU_FREE(setp); +} + int main(int argc, char *argv[]) { struct sock_filter bitmap_filter[] = { @@ -153,6 +178,8 @@ int main(int argc, char *argv[]) system("grep -H . /proc/sys/net/core/bpf_jit_enable"); system("grep -H . /proc/sys/net/core/bpf_jit_harden"); + affinity(); + if (argc > 1) samples = strtoull(argv[1], NULL, 0); else
The seccomp benchmark test (for validating the benefit of bitmaps) can be sensitive to scheduling speed, so pin the process to a single CPU, which appears to significantly improve reliability. Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402061002.3a8722fd-oliver.sang@intel.com Cc: Mark Brown <broonie@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Will Drewry <wad@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> --- .../selftests/seccomp/seccomp_benchmark.c | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+)