apparmor: global buffers spin lock may get contended

Sergey Senozhatsky senozhatsky at chromium.org
Tue Jul 13 13:19:52 UTC 2021


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?



More information about the Linux-security-module-archive mailing list