On Tue, Sep 01, 2026 at 05:35:12PM -0400, Paul Moore wrote: > On Aug 6, 2026 Stanislav Kinsburskii <[email protected]> wrote: > > > > Add a microbenchmark which repeatedly invokes getpid(2) and reports the > > per-operation latency across multiple repetitions. The workload avoids > > filesystem and other syscall-specific work so the fixed audit syscall > > overhead remains visible. > > > > The benchmark deliberately leaves audit policy management to the caller. > > This permits comparisons with increasing numbers of unrelated exit rules > > and with automatically removed watch or tree rules without modifying an > > existing policy unexpectedly. > > > > Signed-off-by: Stanislav Kinsburskii <[email protected]> > > --- > > MAINTAINERS | 1 + > > tools/testing/selftests/Makefile | 1 + > > tools/testing/selftests/audit/.gitignore | 2 + > > tools/testing/selftests/audit/Makefile | 9 ++ > > tools/testing/selftests/audit/README | 30 ++++ > > tools/testing/selftests/audit/audit_bench.c | 227 > > ++++++++++++++++++++++++++++ > > 6 files changed, 270 insertions(+) > > Thanks for this Stanislav, but I'm not certain that we want to merge this > into the kernel and have this become the defacto standard for audit > performance. It's a simple, easy to understand test, but I worry that it > might be too simplistic to properly characterize audit performance. > > ... and no, I'm sorry, but I don't have a better suggestion off the top > of my head :) > > However, audit_bench might be useful as part of the manual_tests in the > audit-testsuite? > > https://github.com/linux-audit/audit-testsuite >
Sure, here is a PR: https://github.com/linux-audit/audit-testsuite/pull/129 Thanks, Stanislav > -- > paul-moore.com
