Skip to contentSkip to conversation

vethpair creation performance, 3.14 versus 4.2.0

DISCUSSION Rick Jones 3 participants 4 messages Aug 31, 2015

Subsystems (2)
lore
Share & tools
lore

Rick Jones

author
#0 lore raw
Quoted 2 lines · Raghavendra K T

Please note that similar overhead was also reported while creating veth pairs https://lkml.org/lkml/2013/3/19/556

That got me curious, so I took the veth pair creation script from there, and started running it out to 10K pairs, comparing a 3.14.44 kernel with a 4.2.0-rc4+ from net-next and then net-next after pulling to get the snmp stat aggregation perf change (4.2.0-rc8+).

Indeed, the 4.2.0-rc8+ kernel with the change was faster than the 4.2.0-rc4+ kernel without it, but both were slower than the 3.14.44 kernel.

I've put a spreadsheet with the results at:

ftp://ftp.netperf.org/vethpair/vethpair_compare.ods

A perf top for the 4.20-rc8+ kernel from the net-next tree looks like this out around 10K pairs:

PerfTop: 11155 irqs/sec kernel:94.2% exact: 0.0% [4000Hz
cycles], (all, 32 CPUs)
-------------------------------------------------------------------------------

    23.44%  [kernel]       [k] vsscanf
     7.32%  [kernel]       [k] mutex_spin_on_owner.isra.4
     5.63%  [kernel]       [k] __memcpy
     5.27%  [kernel]       [k] __dev_alloc_name
     3.46%  [kernel]       [k] format_decode
     3.44%  [kernel]       [k] vsnprintf
     3.16%  [kernel]       [k] acpi_os_write_port
     2.71%  [kernel]       [k] number.isra.13
     1.50%  [kernel]       [k] strncmp
     1.21%  [kernel]       [k] _parse_integer
     0.93%  [kernel]       [k] filemap_map_pages
     0.82%  [kernel]       [k] put_dec_trunc8
     0.82%  [kernel]       [k] unmap_single_vma
     0.78%  [kernel]       [k] native_queued_spin_lock_slowpath
     0.71%  [kernel]       [k] menu_select
     0.65%  [kernel]       [k] clear_page
     0.64%  [kernel]       [k] _raw_spin_lock
     0.62%  [kernel]       [k] page_fault
     0.60%  [kernel]       [k] find_busiest_group
     0.53%  [kernel]       [k] snprintf
     0.52%  [kernel]       [k] int_sqrt
     0.46%  [kernel]       [k] simple_strtoull
     0.44%  [kernel]       [k] page_remove_rmap

My attempts to get a call-graph have been met with very limited success.
Even though I've installed the dbg package from "make deb-pkg" the
symbol resolution doesn't seem to be working.

happy benchmarking,

rick jones

#1 lore raw
Quoted 3 lines · Rick Jones

My attempts to get a call-graph have been met with very limited success.
Even though I've installed the dbg package from "make deb-pkg" the
symbol resolution doesn't seem to be working.

Looks like Debian does not enable framepointers by default:

$ grep FRAME /boot/config-3.2.0-4-amd64
...
# CONFIG_FRAME_POINTER is not set

Similar result for jessie.

author
#2 lore raw
Quoted 5 lines · David Ahern
Quoted 3 lines · Rick Jones

My attempts to get a call-graph have been met with very limited success.
Even though I've installed the dbg package from "make deb-pkg" the
symbol resolution doesn't seem to be working.

Quoted 7 lines

Looks like Debian does not enable framepointers by default:

$ grep FRAME /boot/config-3.2.0-4-amd64
...
# CONFIG_FRAME_POINTER is not set

Similar result for jessie.

And indeed, my config file has a Debian lineage.

rick

#3 lore raw
In reply to Rick Jones
Quoted 48 lines · Rick Jones
Quoted 2 lines · Raghavendra K T

Please note that similar overhead was also reported while creating veth pairs https://lkml.org/lkml/2013/3/19/556

That got me curious, so I took the veth pair creation script from there, and started running it out to 10K pairs, comparing a 3.14.44 kernel with a 4.2.0-rc4+ from net-next and then net-next after pulling to get the snmp stat aggregation perf change (4.2.0-rc8+).

Indeed, the 4.2.0-rc8+ kernel with the change was faster than the 4.2.0-rc4+ kernel without it, but both were slower than the 3.14.44 kernel.

I've put a spreadsheet with the results at:

ftp://ftp.netperf.org/vethpair/vethpair_compare.ods

A perf top for the 4.20-rc8+ kernel from the net-next tree looks like this out around 10K pairs:

    PerfTop:   11155 irqs/sec  kernel:94.2%  exact:  0.0% [4000Hz 

cycles], (all, 32 CPUs)
-------------------------------------------------------------------------------

     23.44%  [kernel]       [k] vsscanf
      7.32%  [kernel]       [k] mutex_spin_on_owner.isra.4
      5.63%  [kernel]       [k] __memcpy
      5.27%  [kernel]       [k] __dev_alloc_name
      3.46%  [kernel]       [k] format_decode
      3.44%  [kernel]       [k] vsnprintf
      3.16%  [kernel]       [k] acpi_os_write_port
      2.71%  [kernel]       [k] number.isra.13
      1.50%  [kernel]       [k] strncmp
      1.21%  [kernel]       [k] _parse_integer
      0.93%  [kernel]       [k] filemap_map_pages
      0.82%  [kernel]       [k] put_dec_trunc8
      0.82%  [kernel]       [k] unmap_single_vma
      0.78%  [kernel]       [k] native_queued_spin_lock_slowpath
      0.71%  [kernel]       [k] menu_select
      0.65%  [kernel]       [k] clear_page
      0.64%  [kernel]       [k] _raw_spin_lock
      0.62%  [kernel]       [k] page_fault
      0.60%  [kernel]       [k] find_busiest_group
      0.53%  [kernel]       [k] snprintf
      0.52%  [kernel]       [k] int_sqrt
      0.46%  [kernel]       [k] simple_strtoull
      0.44%  [kernel]       [k] page_remove_rmap
Quoted 3 lines

My attempts to get a call-graph have been met with very limited success.
Even though I've installed the dbg package from "make deb-pkg" the
symbol resolution doesn't seem to be working.

Well, you do not need call graph to spot the well known issue with __dev_alloc_name() which has O(N) behavior

If we really need to be fast here, and keep eth%d or veth%d names with guarantee of lowest numbers, we would need an IDR