Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1412389 > unrolled thread
| Started by | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| First post | 2016-06-02 18:10 +0200 |
| Last post | 2016-06-08 00:00 +0200 |
| Articles | 7 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression Johannes Weiner <hannes@cmpxchg.org> - 2016-06-02 18:10 +0200
Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression Ye Xiaolong <xiaolong.ye@intel.com> - 2016-06-03 04:30 +0200
Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression Mel Gorman <mgorman@suse.de> - 2016-06-03 11:10 +0200
Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression Johannes Weiner <hannes@cmpxchg.org> - 2016-06-04 00:30 +0200
Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression Ye Xiaolong <xiaolong.ye@intel.com> - 2016-06-06 11:00 +0200
Re: [LKP] [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression Ye Xiaolong <xiaolong.ye@intel.com> - 2016-06-07 07:00 +0200
Re: [LKP] [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression Johannes Weiner <hannes@cmpxchg.org> - 2016-06-08 00:00 +0200
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Date | 2016-06-02 18:10 +0200 |
| Subject | Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression |
| Message-ID | <rFDm1-82K-17@gated-at.bofh.it> |
Hi,
On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote:
> FYI, we noticed pixz.throughput -9.1% regression due to commit:
>
> commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd watermarks in proportion to memory")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> in testcase: pixz
> on test machine: ivb43: 48 threads Ivytown Ivy Bridge-EP with 64G memory with following parameters: cpufreq_governor=performance/nr_threads=100%
Xiaolong, thanks for the report.
It looks like the regression stems from a change in NUMA placement:
> 3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55
> ---------------- --------------------------
> %stddev %change %stddev
> \ | \
> 78505362 ± 0% -9.1% 71324131 ± 0% pixz.throughput
> 4530 ± 0% +1.0% 4575 ± 0% pixz.time.percent_of_cpu_this_job_got
> 14911 ± 0% +2.3% 15251 ± 0% pixz.time.user_time
> 6586930 ± 0% -7.5% 6093751 ± 1% pixz.time.voluntary_context_switches
> 49869 ± 1% -9.0% 45401 ± 0% vmstat.system.cs
> 26406 ± 4% -9.4% 23922 ± 5% numa-meminfo.node0.SReclaimable
> 4803 ± 85% -87.0% 625.25 ± 16% numa-meminfo.node1.Inactive(anon)
> 946.75 ± 3% +775.4% 8288 ± 1% proc-vmstat.nr_alloc_batch
> 2403080 ± 2% -58.4% 999765 ± 0% proc-vmstat.pgalloc_dma32
a bit clearer in the will-it-scale report:
> 3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55
> ---------------- --------------------------
> %stddev %change %stddev
> \ | \
> 442409 ± 0% -8.5% 404670 ± 0% will-it-scale.per_process_ops
> 397397 ± 0% -6.2% 372741 ± 0% will-it-scale.per_thread_ops
> 0.11 ± 1% -15.1% 0.10 ± 0% will-it-scale.scalability
> 9933 ± 10% +17.8% 11696 ± 4% will-it-scale.time.involuntary_context_switches
> 5158470 ± 3% +5.4% 5438873 ± 0% will-it-scale.time.maximum_resident_set_size
> 10701739 ± 0% -11.6% 9456315 ± 0% will-it-scale.time.minor_page_faults
> 825.00 ± 0% +7.8% 889.75 ± 0% will-it-scale.time.percent_of_cpu_this_job_got
> 2484 ± 0% +7.8% 2678 ± 0% will-it-scale.time.system_time
> 81.98 ± 0% +8.7% 89.08 ± 0% will-it-scale.time.user_time
> 848972 ± 1% -13.3% 735967 ± 0% will-it-scale.time.voluntary_context_switches
> 19395253 ± 0% -20.0% 15511908 ± 0% numa-numastat.node0.local_node
> 19400671 ± 0% -20.0% 15518877 ± 0% numa-numastat.node0.numa_hit
The way this test is set up (in-memory compression on 48 nodes) I'm
surprised we spill over, though, even with the higher watermarks.
Xiaolong, could you provide the full /proc/zoneinfo of that machine
right before the test is running? I wonder if it's mostly filled with
cache, and the increase in watermarks causes a higher portion of the
anon allocs and frees to spill to the remote node, but never enough to
enter the allocator slowpath and waking kswapd to fix it.
Another suspect is the fair zone allocator, whose allocation batches
increased as well. It shouldn't affect NUMA placement, but I wonder if
there is a bug in there that causes false spilling to foreign nodes
that was only bounded by the allocation batch of the foreign zone.
Mel, does such a symptom sound familiar in any way?
I'll continue to investigate.
[toc] | [next] | [standalone]
| From | Ye Xiaolong <xiaolong.ye@intel.com> |
|---|---|
| Date | 2016-06-03 04:30 +0200 |
| Message-ID | <rFN21-5JP-5@gated-at.bofh.it> |
| In reply to | #1412389 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote:
>Hi,
>
>On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote:
>> FYI, we noticed pixz.throughput -9.1% regression due to commit:
>>
>> commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd watermarks in proportion to memory")
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>
>> in testcase: pixz
>> on test machine: ivb43: 48 threads Ivytown Ivy Bridge-EP with 64G memory with following parameters: cpufreq_governor=performance/nr_threads=100%
>
>Xiaolong, thanks for the report.
>
>It looks like the regression stems from a change in NUMA placement:
>
>> 3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55
>> ---------------- --------------------------
>> %stddev %change %stddev
>> \ | \
>> 78505362 ± 0% -9.1% 71324131 ± 0% pixz.throughput
>> 4530 ± 0% +1.0% 4575 ± 0% pixz.time.percent_of_cpu_this_job_got
>> 14911 ± 0% +2.3% 15251 ± 0% pixz.time.user_time
>> 6586930 ± 0% -7.5% 6093751 ± 1% pixz.time.voluntary_context_switches
>> 49869 ± 1% -9.0% 45401 ± 0% vmstat.system.cs
>> 26406 ± 4% -9.4% 23922 ± 5% numa-meminfo.node0.SReclaimable
>> 4803 ± 85% -87.0% 625.25 ± 16% numa-meminfo.node1.Inactive(anon)
>> 946.75 ± 3% +775.4% 8288 ± 1% proc-vmstat.nr_alloc_batch
>> 2403080 ± 2% -58.4% 999765 ± 0% proc-vmstat.pgalloc_dma32
>
>a bit clearer in the will-it-scale report:
>
>> 3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55
>> ---------------- --------------------------
>> %stddev %change %stddev
>> \ | \
>> 442409 ± 0% -8.5% 404670 ± 0% will-it-scale.per_process_ops
>> 397397 ± 0% -6.2% 372741 ± 0% will-it-scale.per_thread_ops
>> 0.11 ± 1% -15.1% 0.10 ± 0% will-it-scale.scalability
>> 9933 ± 10% +17.8% 11696 ± 4% will-it-scale.time.involuntary_context_switches
>> 5158470 ± 3% +5.4% 5438873 ± 0% will-it-scale.time.maximum_resident_set_size
>> 10701739 ± 0% -11.6% 9456315 ± 0% will-it-scale.time.minor_page_faults
>> 825.00 ± 0% +7.8% 889.75 ± 0% will-it-scale.time.percent_of_cpu_this_job_got
>> 2484 ± 0% +7.8% 2678 ± 0% will-it-scale.time.system_time
>> 81.98 ± 0% +8.7% 89.08 ± 0% will-it-scale.time.user_time
>> 848972 ± 1% -13.3% 735967 ± 0% will-it-scale.time.voluntary_context_switches
>> 19395253 ± 0% -20.0% 15511908 ± 0% numa-numastat.node0.local_node
>> 19400671 ± 0% -20.0% 15518877 ± 0% numa-numastat.node0.numa_hit
>
>The way this test is set up (in-memory compression on 48 nodes) I'm
>surprised we spill over, though, even with the higher watermarks.
>
>Xiaolong, could you provide the full /proc/zoneinfo of that machine
>right before the test is running? I wonder if it's mostly filled with
Hi, Johannes
Please refer to attached proc-zoneinfo file which was obtained by cat /proc/zoneinfo
on test machine ivb43 right before the test (pigxz) was launched.
Thanks,
Xiaolong
>cache, and the increase in watermarks causes a higher portion of the
>anon allocs and frees to spill to the remote node, but never enough to
>enter the allocator slowpath and waking kswapd to fix it.
>
>Another suspect is the fair zone allocator, whose allocation batches
>increased as well. It shouldn't affect NUMA placement, but I wonder if
>there is a bug in there that causes false spilling to foreign nodes
>that was only bounded by the allocation batch of the foreign zone.
>Mel, does such a symptom sound familiar in any way?
>
>I'll continue to investigate.
[toc] | [prev] | [next] | [standalone]
| From | Mel Gorman <mgorman@suse.de> |
|---|---|
| Date | 2016-06-03 11:10 +0200 |
| Message-ID | <rFTh8-1eC-27@gated-at.bofh.it> |
| In reply to | #1412389 |
On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote: > right before the test is running? I wonder if it's mostly filled with > cache, and the increase in watermarks causes a higher portion of the > anon allocs and frees to spill to the remote node, but never enough to > enter the allocator slowpath and waking kswapd to fix it. > > Another suspect is the fair zone allocator, whose allocation batches > increased as well. It shouldn't affect NUMA placement, but I wonder if > there is a bug in there that causes false spilling to foreign nodes > that was only bounded by the allocation batch of the foreign zone. > Mel, does such a symptom sound familiar in any way? > Unfortunately not. The closest I've seen recently is bugs in the page allocator patches that artifically enters the slow path prematurely but that does not appear to apply here. -- Mel Gorman SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Date | 2016-06-04 00:30 +0200 |
| Message-ID | <rG5Lk-AU-59@gated-at.bofh.it> |
| In reply to | #1412389 |
On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote:
> Hi,
>
> On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote:
> > FYI, we noticed pixz.throughput -9.1% regression due to commit:
> >
> > commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd watermarks in proportion to memory")
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >
> > in testcase: pixz
> > on test machine: ivb43: 48 threads Ivytown Ivy Bridge-EP with 64G memory with following parameters: cpufreq_governor=performance/nr_threads=100%
>
> Xiaolong, thanks for the report.
>
> It looks like the regression stems from a change in NUMA placement:
Scratch that, I was misreading the test results. It's just fewer
allocations in general that happen during the fixed testing time.
I'm stumped by this report. All this patch does other than affect page
reclaim (which is not involved here) is increase the size of the round
robin batches in the fair zone allocator. That should *reduce* work in
the page allocator, if anything.
But I also keep failing to reproduce this - having tried it on the
third machine now - neither pixz nor will-it-scale/page_fault1 give me
that -8-9% regression:
4.5.0-02574-g3ed3a4f:
PIXZ-good.log:throughput: 39908733.604941994
PIXZ-good.log:throughput: 37067947.25049969
PIXZ-good.log:throughput: 38604938.39131216
4.5.0-02575-g795ae7a:
PIXZ-bad.log:throughput: 39489120.87179377
PIXZ-bad.log:throughput: 39307299.288432725
PIXZ-bad.log:throughput: 38795994.3329781
Is this reliably reproducible with 3ed3a4f vs 795ae7a?
Could I ask you to retry the test with Linus's current head as well as
with 795ae7a reverted on top of it? (It's a clean revert.)
Thanks
[toc] | [prev] | [next] | [standalone]
| From | Ye Xiaolong <xiaolong.ye@intel.com> |
|---|---|
| Date | 2016-06-06 11:00 +0200 |
| Message-ID | <rGYy6-2yM-29@gated-at.bofh.it> |
| In reply to | #1413542 |
On Fri, Jun 03, 2016 at 06:21:09PM -0400, Johannes Weiner wrote:
>On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote:
>> Hi,
>>
>> On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote:
>> > FYI, we noticed pixz.throughput -9.1% regression due to commit:
>> >
>> > commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd watermarks in proportion to memory")
>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> >
>> > in testcase: pixz
>> > on test machine: ivb43: 48 threads Ivytown Ivy Bridge-EP with 64G memory with following parameters: cpufreq_governor=performance/nr_threads=100%
>>
>> Xiaolong, thanks for the report.
>>
>> It looks like the regression stems from a change in NUMA placement:
>
>Scratch that, I was misreading the test results. It's just fewer
>allocations in general that happen during the fixed testing time.
>
>I'm stumped by this report. All this patch does other than affect page
>reclaim (which is not involved here) is increase the size of the round
>robin batches in the fair zone allocator. That should *reduce* work in
>the page allocator, if anything.
>
>But I also keep failing to reproduce this - having tried it on the
>third machine now - neither pixz nor will-it-scale/page_fault1 give me
>that -8-9% regression:
>
>4.5.0-02574-g3ed3a4f:
>PIXZ-good.log:throughput: 39908733.604941994
>PIXZ-good.log:throughput: 37067947.25049969
>PIXZ-good.log:throughput: 38604938.39131216
>
>4.5.0-02575-g795ae7a:
> PIXZ-bad.log:throughput: 39489120.87179377
> PIXZ-bad.log:throughput: 39307299.288432725
> PIXZ-bad.log:throughput: 38795994.3329781
>
>Is this reliably reproducible with 3ed3a4f vs 795ae7a?
Yes, it can be stably reproduced in LKP environment, I've run 3ed3a4f0ddffece9
for 4 times, and 795ae7a0de6b834a0cc202aa55 for 7 times.
3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55
---------------- --------------------------
fail:runs %reproduction fail:runs
| | |
:4 50% 2:7 kmsg.Spurious_LAPIC_timer_interrupt_on_cpu
%stddev %change %stddev
\ | \
78505362 ± 0% -9.2% 71298182 ± 0% pixz.throughput
>
>Could I ask you to retry the test with Linus's current head as well as
>with 795ae7a reverted on top of it? (It's a clean revert.)
>
Sure, I have queued the test tasks for them, will update the comparison
once I get the results.
Thanks,
Xiaolong
>Thanks
[toc] | [prev] | [next] | [standalone]
| From | Ye Xiaolong <xiaolong.ye@intel.com> |
|---|---|
| Date | 2016-06-07 07:00 +0200 |
| Subject | Re: [LKP] [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression |
| Message-ID | <rHhhn-6ua-15@gated-at.bofh.it> |
| In reply to | #1414790 |
On Mon, Jun 06, 2016 at 04:53:07PM +0800, Ye Xiaolong wrote:
>On Fri, Jun 03, 2016 at 06:21:09PM -0400, Johannes Weiner wrote:
>>On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote:
>>> Hi,
>>>
>>> On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote:
>>> > FYI, we noticed pixz.throughput -9.1% regression due to commit:
>>> >
>>> > commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd watermarks in proportion to memory")
>>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>> >
>>> > in testcase: pixz
>>> > on test machine: ivb43: 48 threads Ivytown Ivy Bridge-EP with 64G memory with following parameters: cpufreq_governor=performance/nr_threads=100%
>>>
>>> Xiaolong, thanks for the report.
>>>
>>> It looks like the regression stems from a change in NUMA placement:
>>
>>Scratch that, I was misreading the test results. It's just fewer
>>allocations in general that happen during the fixed testing time.
>>
>>I'm stumped by this report. All this patch does other than affect page
>>reclaim (which is not involved here) is increase the size of the round
>>robin batches in the fair zone allocator. That should *reduce* work in
>>the page allocator, if anything.
>>
>>But I also keep failing to reproduce this - having tried it on the
>>third machine now - neither pixz nor will-it-scale/page_fault1 give me
>>that -8-9% regression:
>>
>>4.5.0-02574-g3ed3a4f:
>>PIXZ-good.log:throughput: 39908733.604941994
>>PIXZ-good.log:throughput: 37067947.25049969
>>PIXZ-good.log:throughput: 38604938.39131216
>>
>>4.5.0-02575-g795ae7a:
>> PIXZ-bad.log:throughput: 39489120.87179377
>> PIXZ-bad.log:throughput: 39307299.288432725
>> PIXZ-bad.log:throughput: 38795994.3329781
>>
>>Is this reliably reproducible with 3ed3a4f vs 795ae7ay?
>
>Yes, it can be stably reproduced in LKP environment, I've run 3ed3a4f0ddffece9
>for 4 times, and 795ae7a0de6b834a0cc202aa55 for 7 times.
>
>3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55
>---------------- --------------------------
> fail:runs %reproduction fail:runs
> | | |
> :4 50% 2:7 kmsg.Spurious_LAPIC_timer_interrupt_on_cpu
> %stddev %change %stddev
> \ | \
> 78505362 ± 0% -9.2% 71298182 ± 0% pixz.throughput
>
>
>>
>>Could I ask you to retry the test with Linus's current head as well as
>>with 795ae7a reverted on top of it? (It's a clean revert.)
>>
>
>Sure, I have queued the test tasks for them, will update the comparison
>once I get the results.
FYI, below is the comparison info between 3ed3a4f, 795ae7ay, v4.7-rc2 and the
revert commit (eaa7f0d).
=========================================================================================
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/testcase:
gcc-4.9/performance/x86_64-rhel/100%/debian-x86_64-2015-02-07.cgz/ivb43/pixz
commit:
3ed3a4f0ddffece942bb2661924d87be4ce63cb7
795ae7a0de6b834a0cc202aa55c190ef81496665
v4.7-rc2
eaa7f0d7239a9508c616f208527cd34eb10ec90f
3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55 v4.7-rc2 eaa7f0d7239a9508c616f20852
---------------- -------------------------- -------------------------- --------------------------
fail:runs %reproduction fail:runs %reproduction fail:runs %reproduction fail:runs
| | | | | | |
:4 50% 2:7 0% :3 33% 1:6 kmsg.Spurious_LAPIC_timer_interrupt_on_cpu
:4 0% :7 0% :3 33% 1:6 kmsg.igb#:#:#:exceed_max#second
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
78505362 ± 0% -9.2% 71298182 ± 0% -11.4% 69554765 ± 0% -9.4% 71129419 ± 0% pixz.throughput
5586220 ± 2% -1.6% 5498492 ± 2% +6.4% 5942217 ± 2% +9.6% 6122002 ± 0% pixz.time.involuntary_context_switches
6560113 ± 0% -0.6% 6518532 ± 0% -0.6% 6519065 ± 0% -1.3% 6475587 ± 0% pixz.time.maximum_resident_set_size
4582198 ± 2% -3.6% 4416275 ± 2% -9.0% 4167645 ± 4% -6.7% 4275069 ± 1% pixz.time.minor_page_faults
4530 ± 0% +1.0% 4575 ± 0% -1.7% 4454 ± 0% -1.5% 4463 ± 0% pixz.time.percent_of_cpu_this_job_got
92.03 ± 0% +5.6% 97.23 ± 11% +30.5% 120.08 ± 1% +30.0% 119.61 ± 0% pixz.time.system_time
14911 ± 0% +2.1% 15218 ± 0% -1.1% 14753 ± 1% -1.1% 14743 ± 0% pixz.time.user_time
6586930 ± 0% -8.4% 6033444 ± 1% -4.4% 6298874 ± 1% -2.4% 6425814 ± 0% pixz.time.voluntary_context_switches
2179703 ± 4% +4.8% 2285049 ± 2% -7.5% 2015162 ± 3% -9.9% 1963644 ± 6% softirqs.RCU
2237 ± 2% -2.9% 2172 ± 7% +21.1% 2709 ± 2% +18.6% 2653 ± 2% uptime.idle
4582198 ± 2% -3.6% 4416275 ± 2% -9.0% 4167645 ± 4% -6.7% 4275069 ± 1% time.minor_page_faults
92.03 ± 0% +5.6% 97.23 ± 11% +30.5% 120.08 ± 1% +30.0% 119.61 ± 0% time.system_time
49869 ± 1% -12.6% 43583 ± 8% -17.9% 40960 ± 0% -16.2% 41807 ± 1% vmstat.system.cs
97890 ± 1% -0.0% 97848 ± 3% +6.9% 104621 ± 2% +7.3% 105000 ± 1% vmstat.system.in
105682 ± 1% +0.6% 106297 ± 1% -85.6% 15257 ± 1% -85.1% 15716 ± 1% meminfo.Active(file)
390126 ± 0% -0.2% 389529 ± 0% +24.0% 483736 ± 0% +23.9% 483288 ± 0% meminfo.Inactive
380750 ± 0% -0.2% 380141 ± 0% +24.6% 474268 ± 0% +24.4% 473841 ± 0% meminfo.Inactive(file)
2401 ±107% +76.9% 4247 ± 79% -99.8% 5.67 ± 22% -99.7% 6.17 ± 34% numa-numastat.node0.other_node
2074670 ± 2% -11.3% 1840052 ± 11% -20.3% 1653661 ± 14% -25.6% 1543123 ± 7% numa-numastat.node1.local_node
2081648 ± 2% -11.4% 1844923 ± 11% -20.6% 1653671 ± 14% -25.9% 1543128 ± 7% numa-numastat.node1.numa_hit
6977 ± 36% -30.2% 4871 ± 66% -99.9% 10.33 ± 19% -99.9% 4.67 ± 26% numa-numastat.node1.other_node
13061458 ± 19% -3.3% 12634644 ± 24% +69.6% 22152177 ± 6% +100.0% 26127040 ± 10% cpuidle.C1-IVT.time
193807 ± 15% +26.8% 245657 ± 76% +102.5% 392490 ± 10% +91.9% 371904 ± 5% cpuidle.C1-IVT.usage
154.75 ± 10% -14.8% 131.86 ± 15% -20.1% 123.67 ± 2% -19.5% 124.50 ± 16% cpuidle.C1E-IVT.usage
8.866e+08 ± 2% -15.6% 7.479e+08 ± 6% +26.7% 1.124e+09 ± 6% +22.7% 1.088e+09 ± 3% cpuidle.C6-IVT.time
93283 ± 0% -13.2% 80988 ± 3% +20.5% 112364 ± 4% +20.3% 112255 ± 4% cpuidle.C6-IVT.usage
8559466 ± 20% -39.3% 5195127 ± 40% -100.0% 157.67 ± 36% -97.5% 211608 ±167% cpuidle.POLL.time
771388 ± 9% -53.4% 359081 ± 52% -100.0% 32.67 ± 15% -100.0% 22.50 ± 34% cpuidle.POLL.usage
94.35 ± 0% +1.0% 95.28 ± 0% -1.8% 92.69 ± 0% -1.6% 92.88 ± 0% turbostat.%Busy
2824 ± 0% +1.0% 2851 ± 0% -1.8% 2774 ± 0% -1.6% 2780 ± 0% turbostat.Avg_MHz
3.57 ± 3% -20.9% 2.83 ± 6% +16.1% 4.15 ± 6% +9.0% 3.89 ± 1% turbostat.CPU%c1
2.07 ± 3% -8.8% 1.89 ± 10% +52.3% 3.16 ± 6% +55.6% 3.23 ± 6% turbostat.CPU%c6
157.67 ± 0% -0.7% 156.51 ± 0% -1.6% 155.20 ± 0% -1.5% 155.38 ± 0% turbostat.CorWatt
0.17 ± 17% -2.9% 0.17 ± 23% +145.7% 0.43 ± 26% +121.0% 0.39 ± 21% turbostat.Pkg%pc2
192.71 ± 0% -0.8% 191.15 ± 0% -1.5% 189.80 ± 0% -1.3% 190.11 ± 0% turbostat.PkgWatt
22.36 ± 0% -8.4% 20.49 ± 0% -10.1% 20.10 ± 0% -8.4% 20.48 ± 0% turbostat.RAMWatt
632.75 ± 3% -1.6% 622.43 ± 3% -19.4% 510.00 ± 0% -19.4% 510.00 ± 0% slabinfo.RAW.active_objs
632.75 ± 3% -1.6% 622.43 ± 3% -19.4% 510.00 ± 0% -19.4% 510.00 ± 0% slabinfo.RAW.num_objs
1512 ± 1% -0.6% 1502 ± 1% -100.0% 0.00 ± -1% -100.0% 0.00 ± -1% slabinfo.UNIX.active_objs
1512 ± 1% -0.6% 1502 ± 1% -100.0% 0.00 ± -1% -100.0% 0.00 ± -1% slabinfo.UNIX.num_objs
766.50 ± 10% +7.5% 823.86 ± 10% -100.0% 0.00 ± -1% -100.0% 0.00 ± -1% slabinfo.avc_xperms_node.active_objs
766.50 ± 10% +7.5% 823.86 ± 10% -100.0% 0.00 ± -1% -100.0% 0.00 ± -1% slabinfo.avc_xperms_node.num_objs
13334 ± 4% +6.9% 14255 ± 4% +11.1% 14817 ± 5% +6.8% 14243 ± 7% slabinfo.kmalloc-512.num_objs
357.00 ± 2% +0.7% 359.43 ± 1% +34.5% 480.33 ± 0% +32.5% 473.17 ± 1% slabinfo.kmalloc-8192.num_objs
8080 ± 3% +1.9% 8233 ± 4% +15.1% 9300 ± 5% +16.0% 9375 ± 1% slabinfo.kmalloc-96.active_objs
8125 ± 3% +1.9% 8281 ± 4% +15.1% 9349 ± 5% +16.3% 9451 ± 1% slabinfo.kmalloc-96.num_objs
Thanks,
Xiaolong
>
>Thanks,
>Xiaolong
>
>>Thanks
>_______________________________________________
>LKP mailing list
>LKP@lists.01.org
>https://lists.01.org/mailman/listinfo/lkp
[toc] | [prev] | [next] | [standalone]
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Date | 2016-06-08 00:00 +0200 |
| Subject | Re: [LKP] [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression |
| Message-ID | <rHxcu-85W-41@gated-at.bofh.it> |
| In reply to | #1415693 |
On Tue, Jun 07, 2016 at 12:48:17PM +0800, Ye Xiaolong wrote:
> FYI, below is the comparison info between 3ed3a4f, 795ae7ay, v4.7-rc2 and the
> revert commit (eaa7f0d).
Thanks for running this.
Alas, I still can not make heads or tails of this, or reproduce it
locally for that matter.
With this test run, there seems to be a significant increase in system time:
> 92.03 ± 0% +5.6% 97.23 ± 11% +30.5% 120.08 ± 1% +30.0% 119.61 ± 0% pixz.time.system_time
Would it be possible to profile the testruns using perf? Maybe we can
find out where the kernel is spending the extra time.
But just to make sure I'm looking at the right code, can you first try
the following patch on top of Linus's current tree and see if that
gets performance back to normal? It's a partial revert of the
watermarks that singles out the fair zone allocator:
From 2015eaad688486d65fcf86185e213fff8506b3fe Mon Sep 17 00:00:00 2001
From: Johannes Weiner <hannes@cmpxchg.org>
Date: Tue, 7 Jun 2016 17:45:03 -0400
Subject: [PATCH] mm: revert fairness batching to before the watermarks were
boosted
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
include/linux/mmzone.h | 2 ++
mm/page_alloc.c | 6 ++++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 02069c2..4565b92 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -327,6 +327,8 @@ struct zone {
/* zone watermarks, access with *_wmark_pages(zone) macros */
unsigned long watermark[NR_WMARK];
+ unsigned long fairbatch;
+
unsigned long nr_reserved_highatomic;
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6903b69..33387ab 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2889,7 +2889,7 @@ static void reset_alloc_batches(struct zone *preferred_zone)
do {
mod_zone_page_state(zone, NR_ALLOC_BATCH,
- high_wmark_pages(zone) - low_wmark_pages(zone) -
+ zone->fairbatch -
atomic_long_read(&zone->vm_stat[NR_ALLOC_BATCH]));
clear_bit(ZONE_FAIR_DEPLETED, &zone->flags);
} while (zone++ != preferred_zone);
@@ -6842,6 +6842,8 @@ static void __setup_per_zone_wmarks(void)
zone->watermark[WMARK_MIN] = tmp;
}
+ zone->fairbatch = tmp >> 2;
+
/*
* Set the kswapd watermarks distance according to the
* scale factor in proportion to available memory, but
@@ -6855,7 +6857,7 @@ static void __setup_per_zone_wmarks(void)
zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + tmp * 2;
__mod_zone_page_state(zone, NR_ALLOC_BATCH,
- high_wmark_pages(zone) - low_wmark_pages(zone) -
+ zone->fairbatch -
atomic_long_read(&zone->vm_stat[NR_ALLOC_BATCH]));
spin_unlock_irqrestore(&zone->lock, flags);
--
2.8.2
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web