[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <YO2S+C7Cw7AS7bsg@google.com>
Date: Tue, 13 Jul 2021 22:19:52 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
John Johansen <john.johansen@...onical.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Tomasz Figa <tfiga@...omium.org>, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org
Subject: apparmor: global buffers spin lock may get contended
Hi,
We've notices that apparmor has switched from using per-CPU buffer pool
and per-CPU spin_lock to a global spin_lock in df323337e507a0009d3db1ea.
This seems to be causing some contention on our build machines (with
quite a bit of cores). Because that global spin lock is a part of the
stat() sys call (and perhaps some other)
E.g.
- 9.29% 0.00% clang++ [kernel.vmlinux]
- 9.28% entry_SYSCALL_64_after_hwframe
- 8.98% do_syscall_64
- 7.43% __do_sys_newlstat
- 7.43% vfs_statx
- 7.18% security_inode_getattr
- 7.15% apparmor_inode_getattr
- aa_path_perm
- 3.53% aa_get_buffer
- 3.47% _raw_spin_lock
3.44% native_queued_spin_lock_slowpath
- 3.49% aa_put_buffer.part.0
- 3.45% _raw_spin_lock
3.43% native_queued_spin_lock_slowpath
Can we fix this contention?
Powered by blists - more mailing lists