Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
David Ahern writes: > On 9/23/15 6:37 PM, Huang Ying wrote: >>> >>> I take it you have CONFIG_NET_VRF enabled. correct? >>> >>> With it disabled I see no relevant change in performance between >>> 8f58336d3f78 and 192132b9a034. Can you confirm? >> >> The kconfig file is attached with the mail. It appears that >> CONFIG_NET_VRF is disabled. >> > > Something is not adding up. I anticipate access to a multi-socket numa > system in the next few days. Until then a couple of questions: > > 1. do you take patches to run your tests? No. We checkout your commits and test them. Without applying any other patches. > 2. do you have a wiki/web page with all of the tests run? Sorry, we still have no this information now. > I'd like to > know what other networking tests have been run. Only this one was > flagged, so I presume it means other tests did not hit the > threshold. I would like to know what other tests are run. For the commit and its parent, we have only tested the benchmark in the report email. Best Regards, Huang, Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
David Ahernwrites: > On 9/23/15 6:37 PM, Huang Ying wrote: >>> >>> I take it you have CONFIG_NET_VRF enabled. correct? >>> >>> With it disabled I see no relevant change in performance between >>> 8f58336d3f78 and 192132b9a034. Can you confirm? >> >> The kconfig file is attached with the mail. It appears that >> CONFIG_NET_VRF is disabled. >> > > Something is not adding up. I anticipate access to a multi-socket numa > system in the next few days. Until then a couple of questions: > > 1. do you take patches to run your tests? No. We checkout your commits and test them. Without applying any other patches. > 2. do you have a wiki/web page with all of the tests run? Sorry, we still have no this information now. > I'd like to > know what other networking tests have been run. Only this one was > flagged, so I presume it means other tests did not hit the > threshold. I would like to know what other tests are run. For the commit and its parent, we have only tested the benchmark in the report email. Best Regards, Huang, Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On 9/23/15 6:37 PM, Huang Ying wrote: I take it you have CONFIG_NET_VRF enabled. correct? With it disabled I see no relevant change in performance between 8f58336d3f78 and 192132b9a034. Can you confirm? The kconfig file is attached with the mail. It appears that CONFIG_NET_VRF is disabled. Something is not adding up. I anticipate access to a multi-socket numa system in the next few days. Until then a couple of questions: 1. do you take patches to run your tests? 2. do you have a wiki/web page with all of the tests run? I'd like to know what other networking tests have been run. Only this one was flagged, so I presume it means other tests did not hit the threshold. I would like to know what other tests are run. Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On 9/20/15 7:33 PM, Huang Ying wrote: Also, this is the end patch of a series that first refactors and then adds a capability. The more relevant comparison is 8f58336d3f78 to 192132b9a034 (8f58336d3f78 is the commit before the series). Is it possible to get this test run on your system comparing those 2 commits? I take it you have CONFIG_NET_VRF enabled. correct? With it disabled I see no relevant change in performance between 8f58336d3f78 and 192132b9a034. Can you confirm? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On 9/20/15 7:33 PM, Huang Ying wrote: Also, this is the end patch of a series that first refactors and then adds a capability. The more relevant comparison is 8f58336d3f78 to 192132b9a034 (8f58336d3f78 is the commit before the series). Is it possible to get this test run on your system comparing those 2 commits? I take it you have CONFIG_NET_VRF enabled. correct? With it disabled I see no relevant change in performance between 8f58336d3f78 and 192132b9a034. Can you confirm? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On 9/23/15 6:37 PM, Huang Ying wrote: I take it you have CONFIG_NET_VRF enabled. correct? With it disabled I see no relevant change in performance between 8f58336d3f78 and 192132b9a034. Can you confirm? The kconfig file is attached with the mail. It appears that CONFIG_NET_VRF is disabled. Something is not adding up. I anticipate access to a multi-socket numa system in the next few days. Until then a couple of questions: 1. do you take patches to run your tests? 2. do you have a wiki/web page with all of the tests run? I'd like to know what other networking tests have been run. Only this one was flagged, so I presume it means other tests did not hit the threshold. I would like to know what other tests are run. Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On 9/20/15 7:33 PM, Huang Ying wrote: Clarification: The reproduce file shows 128 instances of 'netperf -t TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does that mean these 128 commands are run serially? Sorry. It's a script bug, there should be a "&" on the end. Will fix the script. Ok. Also, this is the end patch of a series that first refactors and then adds a capability. The more relevant comparison is 8f58336d3f78 to 192132b9a034 (8f58336d3f78 is the commit before the series). Is it possible to get this test run on your system comparing those 2 commits? Sure. It is attached with the mail. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On Sun, 2015-09-20 at 19:19 -0600, David Ahern wrote: > On 9/20/15 6:30 AM, kernel test robot wrote: > > FYI, we noticed the below changes on > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support > > for VRFs to inetpeer cache") > > > > > > === > > == > > tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtim > > e/nr_threads/cluster/test: > >lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc > > -4.9/performance/300s/200%/cs-localhost/TCP_CRR > > > > commit: > >5345c2e12d41f815c1009c9dee72f3d5fcfd4282 > >192132b9a034d87566294be0fba5f8f75c2cf16b > > > > Clarification: The reproduce file shows 128 instances of 'netperf -t > TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does > that > mean these 128 commands are run serially? Sorry. It's a script bug, there should be a "&" on the end. Will fix the script. > > Also, this is the end patch of a series that first refactors and then > adds a capability. The more relevant comparison is 8f58336d3f78 to > 192132b9a034 (8f58336d3f78 is the commit before the series). Is it > possible to get this test run on your system comparing those 2 > commits? Sure. It is attached with the mail. Best Regards, Huang, Ying = tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtime/nr_threads/cluster/test: lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/300s/200%/cs-localhost/TCP_CRR commit: 8f58336d3f78aef61c8023c18546155f5fdf3224 192132b9a034d87566294be0fba5f8f75c2cf16b 8f58336d3f78aef6 192132b9a034d87566294be0fb -- %stddev %change %stddev \ |\ 2825 ± 2% -17.0% 2344 ± 1% netperf.Throughput_tps 1.089e+08 ± 2% -16.9% 90493497 ± 1% netperf.time.involuntary_context_switches 1.086e+08 ± 2% -17.0% 90186076 ± 1% netperf.time.minor_page_faults 4599 ± 0% +10.1% 5062 ± 1% netperf.time.percent_of_cpu_this_job_got 13112 ± 0% +12.0% 14686 ± 1% netperf.time.system_time 940.67 ± 2% -16.9% 781.88 ± 1% netperf.time.user_time 1.085e+08 ± 2% -17.0% 90055371 ± 1% netperf.time.voluntary_context_switches 4.342e+08 ± 2% -17.0% 3.604e+08 ± 1% softirqs.NET_RX 2258 ± 1% +10.4% 2494 ± 4% uptime.idle 320.54 ± 0% -2.4% 312.95 ± 0% turbostat.CorWatt 376.48 ± 0% -2.0% 368.88 ± 0% turbostat.PkgWatt 1420157 ± 2% -16.9%1180769 ± 1% vmstat.system.cs 68961 ± 0% +1.0% 69635 ± 0% vmstat.system.in 18193082 ± 11% -14.3% 15594591 ± 16% cpuidle.C1-SNB.time 3054463 ± 16% +45.0%4428730 ± 19% cpuidle.C1E-SNB.time 238.50 ± 29% +5507.2% 13373 ± 83% cpuidle.C6-SNB.time 1.119e+08 ± 2% -16.9% 93008884 ± 1% proc-vmstat.numa_hit 1.119e+08 ± 2% -16.9% 93008682 ± 1% proc-vmstat.numa_local 6365197 ± 2% -18.4%5191906 ± 2% proc-vmstat.pgalloc_dma32 1.07e+08 ± 2% -16.6% 89162443 ± 1% proc-vmstat.pgalloc_normal 1.095e+08 ± 2% -16.9% 91044527 ± 1% proc-vmstat.pgfault 1.133e+08 ± 2% -16.7% 94305253 ± 1% proc-vmstat.pgfree 1.089e+08 ± 2% -16.9% 90493497 ± 1% time.involuntary_context_switches 1.086e+08 ± 2% -17.0% 90186076 ± 1% time.minor_page_faults 4599 ± 0% +10.1% 5062 ± 1% time.percent_of_cpu_this_job_got 13112 ± 0% +12.0% 14686 ± 1% time.system_time 940.67 ± 2% -16.9% 781.88 ± 1% time.user_time 1.085e+08 ± 2% -17.0% 90055371 ± 1% time.voluntary_context_switches 28168329 ± 1% -17.9% 23130696 ± 2% numa-numastat.node0.local_node 28168412 ± 1% -17.9% 23130763 ± 2% numa-numastat.node0.numa_hit 28038183 ± 3% -15.4% 23732122 ± 1% numa-numastat.node1.local_node 28038223 ± 3% -15.4% 23732168 ± 1% numa-numastat.node1.numa_hit 27687321 ± 2% -17.1% 22948672 ± 2% numa-numastat.node2.local_node 27687946 ± 2% -17.1% 22948710 ± 2% numa-numastat.node2.numa_hit 27979864 ± 2% -17.1% 23200094 ± 1% numa-numastat.node3.local_node 27980945 ± 2% -17.1% 23200610 ± 1% numa-numastat.node3.numa_hit 1080 ± 93% -52.3% 515.75 ±157% numa-numastat.node3.other_node 90608 ± 2% -11.3% 80327 ± 1% slabinfo.Acpi-State.active_objs 1783 ± 2% -11.3% 1581 ± 1% slabinfo.Acpi-State.active_slabs 90950 ± 2% -11.3% 80684 ± 1% slabinfo.Acpi-State.num_objs 1783 ± 2% -11.3% 1581 ± 1% slabinfo.Acpi-State.num_slabs 45161 ± 4% -27.4% 32776 ±
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On 9/20/15 6:30 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support for VRFs to inetpeer cache") = tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtime/nr_threads/cluster/test: lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/300s/200%/cs-localhost/TCP_CRR commit: 5345c2e12d41f815c1009c9dee72f3d5fcfd4282 192132b9a034d87566294be0fba5f8f75c2cf16b Clarification: The reproduce file shows 128 instances of 'netperf -t TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does that mean these 128 commands are run serially? Also, this is the end patch of a series that first refactors and then adds a capability. The more relevant comparison is 8f58336d3f78 to 192132b9a034 (8f58336d3f78 is the commit before the series). Is it possible to get this test run on your system comparing those 2 commits? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On Sun, 2015-09-20 at 19:19 -0600, David Ahern wrote: > On 9/20/15 6:30 AM, kernel test robot wrote: > > FYI, we noticed the below changes on > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support > > for VRFs to inetpeer cache") > > > > > > === > > == > > tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtim > > e/nr_threads/cluster/test: > >lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc > > -4.9/performance/300s/200%/cs-localhost/TCP_CRR > > > > commit: > >5345c2e12d41f815c1009c9dee72f3d5fcfd4282 > >192132b9a034d87566294be0fba5f8f75c2cf16b > > > > Clarification: The reproduce file shows 128 instances of 'netperf -t > TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does > that > mean these 128 commands are run serially? Sorry. It's a script bug, there should be a "&" on the end. Will fix the script. > > Also, this is the end patch of a series that first refactors and then > adds a capability. The more relevant comparison is 8f58336d3f78 to > 192132b9a034 (8f58336d3f78 is the commit before the series). Is it > possible to get this test run on your system comparing those 2 > commits? Sure. It is attached with the mail. Best Regards, Huang, Ying = tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtime/nr_threads/cluster/test: lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/300s/200%/cs-localhost/TCP_CRR commit: 8f58336d3f78aef61c8023c18546155f5fdf3224 192132b9a034d87566294be0fba5f8f75c2cf16b 8f58336d3f78aef6 192132b9a034d87566294be0fb -- %stddev %change %stddev \ |\ 2825 ± 2% -17.0% 2344 ± 1% netperf.Throughput_tps 1.089e+08 ± 2% -16.9% 90493497 ± 1% netperf.time.involuntary_context_switches 1.086e+08 ± 2% -17.0% 90186076 ± 1% netperf.time.minor_page_faults 4599 ± 0% +10.1% 5062 ± 1% netperf.time.percent_of_cpu_this_job_got 13112 ± 0% +12.0% 14686 ± 1% netperf.time.system_time 940.67 ± 2% -16.9% 781.88 ± 1% netperf.time.user_time 1.085e+08 ± 2% -17.0% 90055371 ± 1% netperf.time.voluntary_context_switches 4.342e+08 ± 2% -17.0% 3.604e+08 ± 1% softirqs.NET_RX 2258 ± 1% +10.4% 2494 ± 4% uptime.idle 320.54 ± 0% -2.4% 312.95 ± 0% turbostat.CorWatt 376.48 ± 0% -2.0% 368.88 ± 0% turbostat.PkgWatt 1420157 ± 2% -16.9%1180769 ± 1% vmstat.system.cs 68961 ± 0% +1.0% 69635 ± 0% vmstat.system.in 18193082 ± 11% -14.3% 15594591 ± 16% cpuidle.C1-SNB.time 3054463 ± 16% +45.0%4428730 ± 19% cpuidle.C1E-SNB.time 238.50 ± 29% +5507.2% 13373 ± 83% cpuidle.C6-SNB.time 1.119e+08 ± 2% -16.9% 93008884 ± 1% proc-vmstat.numa_hit 1.119e+08 ± 2% -16.9% 93008682 ± 1% proc-vmstat.numa_local 6365197 ± 2% -18.4%5191906 ± 2% proc-vmstat.pgalloc_dma32 1.07e+08 ± 2% -16.6% 89162443 ± 1% proc-vmstat.pgalloc_normal 1.095e+08 ± 2% -16.9% 91044527 ± 1% proc-vmstat.pgfault 1.133e+08 ± 2% -16.7% 94305253 ± 1% proc-vmstat.pgfree 1.089e+08 ± 2% -16.9% 90493497 ± 1% time.involuntary_context_switches 1.086e+08 ± 2% -17.0% 90186076 ± 1% time.minor_page_faults 4599 ± 0% +10.1% 5062 ± 1% time.percent_of_cpu_this_job_got 13112 ± 0% +12.0% 14686 ± 1% time.system_time 940.67 ± 2% -16.9% 781.88 ± 1% time.user_time 1.085e+08 ± 2% -17.0% 90055371 ± 1% time.voluntary_context_switches 28168329 ± 1% -17.9% 23130696 ± 2% numa-numastat.node0.local_node 28168412 ± 1% -17.9% 23130763 ± 2% numa-numastat.node0.numa_hit 28038183 ± 3% -15.4% 23732122 ± 1% numa-numastat.node1.local_node 28038223 ± 3% -15.4% 23732168 ± 1% numa-numastat.node1.numa_hit 27687321 ± 2% -17.1% 22948672 ± 2% numa-numastat.node2.local_node 27687946 ± 2% -17.1% 22948710 ± 2% numa-numastat.node2.numa_hit 27979864 ± 2% -17.1% 23200094 ± 1% numa-numastat.node3.local_node 27980945 ± 2% -17.1% 23200610 ± 1% numa-numastat.node3.numa_hit 1080 ± 93% -52.3% 515.75 ±157% numa-numastat.node3.other_node 90608 ± 2% -11.3% 80327 ± 1% slabinfo.Acpi-State.active_objs 1783 ± 2% -11.3% 1581 ± 1% slabinfo.Acpi-State.active_slabs 90950 ± 2% -11.3% 80684 ± 1% slabinfo.Acpi-State.num_objs 1783 ± 2% -11.3% 1581 ± 1% slabinfo.Acpi-State.num_slabs 45161 ± 4% -27.4% 32776 ±
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On 9/20/15 6:30 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support for VRFs to inetpeer cache") = tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtime/nr_threads/cluster/test: lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/300s/200%/cs-localhost/TCP_CRR commit: 5345c2e12d41f815c1009c9dee72f3d5fcfd4282 192132b9a034d87566294be0fba5f8f75c2cf16b Clarification: The reproduce file shows 128 instances of 'netperf -t TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does that mean these 128 commands are run serially? Also, this is the end patch of a series that first refactors and then adds a capability. The more relevant comparison is 8f58336d3f78 to 192132b9a034 (8f58336d3f78 is the commit before the series). Is it possible to get this test run on your system comparing those 2 commits? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
On 9/20/15 7:33 PM, Huang Ying wrote: Clarification: The reproduce file shows 128 instances of 'netperf -t TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does that mean these 128 commands are run serially? Sorry. It's a script bug, there should be a "&" on the end. Will fix the script. Ok. Also, this is the end patch of a series that first refactors and then adds a capability. The more relevant comparison is 8f58336d3f78 to 192132b9a034 (8f58336d3f78 is the commit before the series). Is it possible to get this test run on your system comparing those 2 commits? Sure. It is attached with the mail. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/