On Mon, 2015-08-31 at 12:48 -0700, Rick Jones wrote: > On 08/29/2015 10:59 PM, Raghavendra K T wrote: > > 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.
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
