* [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.