All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] selftests/seccomp: Pin benchmark to single CPU
@ 2024-02-06  9:56 Kees Cook
  2024-02-06 10:16 ` Mark Brown
  0 siblings, 1 reply; 4+ messages in thread
From: Kees Cook @ 2024-02-06  9:56 UTC (permalink / raw)
  To: Mark Brown
  Cc: Kees Cook, kernel test robot, Andy Lutomirski, Will Drewry,
	Shuah Khan, linux-kernel, linux-kselftest, linux-hardening

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(+)

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
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] selftests/seccomp: Pin benchmark to single CPU
  2024-02-06  9:56 [PATCH] selftests/seccomp: Pin benchmark to single CPU Kees Cook
@ 2024-02-06 10:16 ` Mark Brown
  2024-02-06 11:04   ` Kees Cook
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Brown @ 2024-02-06 10:16 UTC (permalink / raw)
  To: Kees Cook
  Cc: kernel test robot, Andy Lutomirski, Will Drewry, Shuah Khan,
	linux-kernel, linux-kselftest, linux-hardening

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] selftests/seccomp: Pin benchmark to single CPU
  2024-02-06 10:16 ` Mark Brown
@ 2024-02-06 11:04   ` Kees Cook
  2024-02-06 11:10     ` Mark Brown
  0 siblings, 1 reply; 4+ messages in thread
From: Kees Cook @ 2024-02-06 11:04 UTC (permalink / raw)
  To: Mark Brown
  Cc: kernel test robot, Andy Lutomirski, Will Drewry, Shuah Khan,
	linux-kernel, linux-kselftest, linux-hardening

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.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] selftests/seccomp: Pin benchmark to single CPU
  2024-02-06 11:04   ` Kees Cook
@ 2024-02-06 11:10     ` Mark Brown
  0 siblings, 0 replies; 4+ messages in thread
From: Mark Brown @ 2024-02-06 11:10 UTC (permalink / raw)
  To: Kees Cook
  Cc: kernel test robot, Andy Lutomirski, Will Drewry, Shuah Khan,
	linux-kernel, linux-kselftest, linux-hardening

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-02-06 11:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-06  9:56 [PATCH] selftests/seccomp: Pin benchmark to single CPU Kees Cook
2024-02-06 10:16 ` Mark Brown
2024-02-06 11:04   ` Kees Cook
2024-02-06 11:10     ` Mark Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.