Skip to content
  • Andrey Vagin's avatar
    net: skip genenerating uevents for network namespaces that are exiting · 002d8a1a
    Andrey Vagin authored
    
    
    No one can see these events, because a network namespace can not be
    destroyed, if it has sockets.
    
    Unlike other devices, uevent-s for network devices are generated
    only inside their network namespaces. They are filtered in
    kobj_bcast_filter()
    
    My experiments shows that net namespaces are destroyed more 30% faster
    with this optimization.
    
    Here is a perf output for destroying network namespaces without this
    patch.
    
    -   94.76%     0.02%  kworker/u48:1  [kernel.kallsyms]     [k] cleanup_net
       - 94.74% cleanup_net
          - 94.64% ops_exit_list.isra.4
             - 41.61% default_device_exit_batch
                - 41.47% unregister_netdevice_many
                   - rollback_registered_many
                      - 40.36% netdev_unregister_kobject
                         - 14.55% device_del
                            + 13.71% kobject_uevent
                         - 13.04% netdev_queue_update_kobjects
                            + 12.96% kobject_put
                         - 12.72% net_rx_queue_update_kobjects
                              kobject_put
                            - kobject_release
                               + 12.69% kobject_uevent
                      + 0.80% call_netdevice_notifiers_info
             + 19.57% nfsd_exit_net
             + 11.15% tcp_net_metrics_exit
             + 8.25% rpcsec_gss_exit_net
    
    It's very critical to optimize the exit path for network namespaces,
    because they are destroyed under net_mutex and many namespaces can be
    destroyed for one iteration.
    
    v2: use dev_set_uevent_suppress()
    
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: default avatarAndrei Vagin <avagin@openvz.org>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    002d8a1a