Skip to content
  • Eric Dumazet's avatar
    af_unix: dont send SCM_CREDENTIALS by default · 16e57262
    Eric Dumazet authored
    Since commit 7361c36c
    
     (af_unix: Allow credentials to work across
    user and pid namespaces) af_unix performance dropped a lot.
    
    This is because we now take a reference on pid and cred in each write(),
    and release them in read(), usually done from another process,
    eventually from another cpu. This triggers false sharing.
    
    # Events: 154K cycles
    #
    # Overhead  Command       Shared Object        Symbol
    # ........  .......  ..................  .........................
    #
        10.40%  hackbench  [kernel.kallsyms]   [k] put_pid
         8.60%  hackbench  [kernel.kallsyms]   [k] unix_stream_recvmsg
         7.87%  hackbench  [kernel.kallsyms]   [k] unix_stream_sendmsg
         6.11%  hackbench  [kernel.kallsyms]   [k] do_raw_spin_lock
         4.95%  hackbench  [kernel.kallsyms]   [k] unix_scm_to_skb
         4.87%  hackbench  [kernel.kallsyms]   [k] pid_nr_ns
         4.34%  hackbench  [kernel.kallsyms]   [k] cred_to_ucred
         2.39%  hackbench  [kernel.kallsyms]   [k] unix_destruct_scm
         2.24%  hackbench  [kernel.kallsyms]   [k] sub_preempt_count
         1.75%  hackbench  [kernel.kallsyms]   [k] fget_light
         1.51%  hackbench  [kernel.kallsyms]   [k]
    __mutex_lock_interruptible_slowpath
         1.42%  hackbench  [kernel.kallsyms]   [k] sock_alloc_send_pskb
    
    This patch includes SCM_CREDENTIALS information in a af_unix message/skb
    only if requested by the sender, [man 7 unix for details how to include
    ancillary data using sendmsg() system call]
    
    Note: This might break buggy applications that expected SCM_CREDENTIAL
    from an unaware write() system call, and receiver not using SO_PASSCRED
    socket option.
    
    If SOCK_PASSCRED is set on source or destination socket, we still
    include credentials for mere write() syscalls.
    
    Performance boost in hackbench : more than 50% gain on a 16 thread
    machine (2 quad-core cpus, 2 threads per core)
    
    hackbench 20 thread 2000
    
    4.228 sec instead of 9.102 sec
    
    Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
    Acked-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    16e57262