From: Mel Gorman <mgorman@techsingularity.net>
To: Dave Chinner <david@fromorbit.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>, Rik van Riel <riel@surriel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/31] Move LRU page reclaim from zones to nodes v8
Date: Mon, 11 Jul 2016 10:02:24 +0100 [thread overview]
Message-ID: <20160711090224.GB9806@techsingularity.net> (raw)
In-Reply-To: <20160711004757.GN12670@dastard>
On Mon, Jul 11, 2016 at 10:47:57AM +1000, Dave Chinner wrote:
> > I had tested XFS with earlier releases and noticed no major problems
> > so later releases tested only one filesystem. Given the changes since,
> > a retest is desirable. I've posted the current version of the series but
> > I'll queue the tests to run over the weekend. They are quite time consuming
> > to run unfortunately.
>
> Understood. I'm not following the patchset all that closely, so I
> didn' know you'd already tested XFS.
>
It was needed anyway. Not all of them completed over the weekend. In
particular, the NUMA machine is taking its time because many of the
workloads are scaled by memory size and it takes longer.
> > On the fsmark configuration, I configured the test to use 4K files
> > instead of 0-sized files that normally would be used to stress inode
> > creation/deletion. This is to have a mix of page cache and slab
> > allocations. Shout if this does not suit your expectations.
>
> Sounds fine. I usually limit that test to 10 million inodes - that's
> my "10-4" test.
>
Thanks.
I'm not going to go through most of the results in detail. The raw data
is verbose and not necessarily useful in most cases.
tiobench
Similar results to ext4, similar performance, similar reclaim
activity
pgbench
Similar performance results to ext4. Minor differences in
reclaim activity. The series did enter direct reclaim which the
mmotm kernel did not. However, it was one minor spike. kswapd
activity was almost identical.
bonnie
Similar performance results to ext4, minor differences in
reclaim activity
parallel dd
Similar performance results to ext4. Small differences in reclaim
activity. Again, there was a slight increase in direct reclaim
activity but negligble in comparison to the overall workload.
Average direct reclaim velocity was 1.8 pages per second and
direct reclaim page scans were 0.018% of all scans.
stutter
Similar performance results to ext4, similar reclaim activity
These observations are all based on two UMA machines.
fsmark 50m-inodes-4k-files-16-threads
=====================================
As fsmark can be variable, this is reported as quartiles. This is one of
the UMA machines;
4.7.0-rc4 4.7.0-rc4
mmotm-20160623 approx-v9r6
Min files/sec-16 2354.80 ( 0.00%) 2255.40 ( -4.22%)
1st-qrtle files/sec-16 3254.90 ( 0.00%) 3249.40 ( -0.17%)
2nd-qrtle files/sec-16 3310.10 ( 0.00%) 3306.70 ( -0.10%)
3rd-qrtle files/sec-16 3353.40 ( 0.00%) 3329.00 ( -0.73%)
Max-90% files/sec-16 3435.70 ( 0.00%) 3426.90 ( -0.26%)
Max-93% files/sec-16 3437.80 ( 0.00%) 3462.50 ( 0.72%)
Max-95% files/sec-16 3471.60 ( 0.00%) 3536.50 ( 1.87%)
Max-99% files/sec-16 5383.90 ( 0.00%) 5900.00 ( 9.59%)
Max files/sec-16 5383.90 ( 0.00%) 5900.00 ( 9.59%)
Mean files/sec-16 3342.99 ( 0.00%) 3329.64 ( -0.40%)
4.7.0-rc4 4.7.0-rc4
mmotm-20160623 approx-v9r6
User 188.46 187.14
System 2964.26 2972.35
Elapsed 10222.83 9865.87
Direct pages scanned 144365 189738
Kswapd pages scanned 13147349 12965288
Kswapd pages reclaimed 13144543 12962266
Direct pages reclaimed 144365 189738
Kswapd efficiency 99% 99%
Kswapd velocity 1286.077 1314.156
Direct efficiency 100% 100%
Direct velocity 14.122 19.232
Percentage direct scans 1% 1%
Slabs scanned 52563968 52672128
Direct inode steals 132 24
Kswapd inode steals 18234 12096
The performance is comparable and so is slab reclaim activity. The NUMA
machine had completed the same test. On the NUMA machine, there is a also
a slight increase in direct reclaim activity but as a tiny percentage
overall. Slab scan and reclaim activity is almost identical.
fsmark 50m-inodes-0k-files-16-threads
=====================================
I also tested with zero-sized files. The UMA machine showed nothing
interesting, the NUMA machine results were as follows;
4.7.0-rc4 4.7.0-rc4
mmotm-20160623 approx-v9r6
Min files/sec-16 108235.50 ( 0.00%) 120783.20 ( 11.59%)
1st-qrtle files/sec-16 129569.40 ( 0.00%) 132300.70 ( 2.11%)
2nd-qrtle files/sec-16 135544.90 ( 0.00%) 141198.40 ( 4.17%)
3rd-qrtle files/sec-16 139634.90 ( 0.00%) 148242.50 ( 6.16%)
Max-90% files/sec-16 144203.60 ( 0.00%) 152247.10 ( 5.58%)
Max-93% files/sec-16 145294.50 ( 0.00%) 152642.20 ( 5.06%)
Max-95% files/sec-16 146009.70 ( 0.00%) 153355.20 ( 5.03%)
Max-99% files/sec-16 148346.80 ( 0.00%) 156353.50 ( 5.40%)
Max files/sec-16 149800.20 ( 0.00%) 158316.50 ( 5.69%)
Mean files/sec-16 133796.64 ( 0.00%) 140393.61 ( 4.93%)
Best99%Mean files/sec-16 149800.20 ( 0.00%) 158316.50 ( 5.69%)
Best95%Mean files/sec-16 147819.92 ( 0.00%) 155778.74 ( 5.38%)
Best90%Mean files/sec-16 146541.61 ( 0.00%) 154254.78 ( 5.26%)
Best50%Mean files/sec-16 140681.59 ( 0.00%) 148236.82 ( 5.37%)
Best10%Mean files/sec-16 135612.91 ( 0.00%) 142230.89 ( 4.88%)
Best5%Mean files/sec-16 134754.93 ( 0.00%) 141343.44 ( 4.89%)
Best1%Mean files/sec-16 134054.83 ( 0.00%) 140591.69 ( 4.88%)
fsmark-threaded App Overhead
4.7.0-rc4 4.7.0-rc4
mmotm-20160623 approx-v9r6
Min overhead-16 3113450.00 ( 0.00%) 2953856.00 ( -5.13%)
Amean overhead-16 3341992.77 ( 0.00%) 3270340.73 ( -2.14%)
Stddev overhead-16 128214.09 ( 0.00%) 137818.89 ( 7.49%)
CoeffVar overhead-16 3.84 ( 0.00%) 4.21 ( -9.85%)
Max overhead-16 3756612.00 ( 0.00%) 3743079.00 ( -0.36%)
4.7.0-rc4 4.7.0-rc4
mmotm-20160623 approx-v9r6
User 242.65 236.67
System 3507.20 3303.89
Elapsed 2201.73 2048.65
Direct pages scanned 261 106
Kswapd pages scanned 170106 59234
Kswapd pages reclaimed 167015 56118
Direct pages reclaimed 261 106
Kswapd efficiency 98% 94%
Kswapd velocity 77.260 28.914
Direct efficiency 100% 100%
Direct velocity 0.119 0.052
Percentage direct scans 0% 0%
Slabs scanned 93341634 92911820
Direct inode steals 0 0
Kswapd inode steals 39 39
The performance is slightly better and there is no major differences in
the reclaim stats.
I'll keep looking at results as they come in but the results so far
look fine.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2016-07-11 9:02 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 15:37 [PATCH 00/31] Move LRU page reclaim from zones to nodes v8 Mel Gorman
2016-07-01 15:37 ` [PATCH 01/31] mm, vmstat: add infrastructure for per-node vmstats Mel Gorman
2016-07-01 15:37 ` [PATCH 02/31] mm, vmscan: move lru_lock to the node Mel Gorman
2016-07-01 15:37 ` [PATCH 03/31] mm, vmscan: move LRU lists to node Mel Gorman
2016-07-01 15:37 ` [PATCH 04/31] mm, vmscan: begin reclaiming pages on a per-node basis Mel Gorman
2016-07-01 15:37 ` [PATCH 05/31] mm, vmscan: have kswapd only scan based on the highest requested zone Mel Gorman
2016-07-01 15:37 ` [PATCH 06/31] mm, vmscan: make kswapd reclaim in terms of nodes Mel Gorman
2016-07-01 15:37 ` [PATCH 07/31] mm, vmscan: remove balance gap Mel Gorman
2016-07-01 15:37 ` [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps Mel Gorman
2016-07-01 15:37 ` [PATCH 09/31] mm, vmscan: by default have direct reclaim only shrink once per node Mel Gorman
2016-07-01 15:37 ` [PATCH 10/31] mm, vmscan: remove duplicate logic clearing node congestion and dirty state Mel Gorman
2016-07-01 15:37 ` [PATCH 11/31] mm: vmscan: do not reclaim from kswapd if there is any eligible zone Mel Gorman
2016-07-01 15:37 ` [PATCH 12/31] mm, vmscan: make shrink_node decisions more node-centric Mel Gorman
2016-07-01 15:37 ` [PATCH 13/31] mm, memcg: move memcg limit enforcement from zones to nodes Mel Gorman
2016-07-01 15:37 ` [PATCH 14/31] mm, workingset: make working set detection node-aware Mel Gorman
2016-07-01 15:37 ` [PATCH 15/31] mm, page_alloc: consider dirtyable memory in terms of nodes Mel Gorman
2016-07-01 15:37 ` [PATCH 16/31] mm: move page mapped accounting to the node Mel Gorman
2016-07-01 15:37 ` [PATCH 17/31] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Mel Gorman
2016-07-01 15:37 ` [PATCH 18/31] mm: move most file-based accounting to the node Mel Gorman
2016-07-01 15:37 ` [PATCH 19/31] mm: move vmscan writes and file write " Mel Gorman
2016-07-01 15:37 ` [PATCH 20/31] mm, vmscan: only wakeup kswapd once per node for the requested classzone Mel Gorman
2016-07-01 15:37 ` [PATCH 21/31] mm, page_alloc: Wake kswapd based on the highest eligible zone Mel Gorman
2016-07-01 15:37 ` [PATCH 22/31] mm: convert zone_reclaim to node_reclaim Mel Gorman
2016-07-01 15:37 ` [PATCH 23/31] mm, vmscan: Avoid passing in classzone_idx unnecessarily to shrink_node Mel Gorman
2016-07-01 15:37 ` [PATCH 24/31] mm, vmscan: Avoid passing in classzone_idx unnecessarily to compaction_ready Mel Gorman
2016-07-01 15:37 ` [PATCH 25/31] mm, vmscan: add classzone information to tracepoints Mel Gorman
2016-07-01 15:37 ` [PATCH 26/31] mm, page_alloc: remove fair zone allocation policy Mel Gorman
2016-07-01 15:37 ` [PATCH 27/31] mm: page_alloc: cache the last node whose dirty limit is reached Mel Gorman
2016-07-01 15:37 ` [PATCH 28/31] mm: vmstat: replace __count_zone_vm_events with a zone id equivalent Mel Gorman
2016-07-01 15:37 ` [PATCH 29/31] mm: vmstat: account per-zone stalls and pages skipped during reclaim Mel Gorman
2016-07-01 15:37 ` [PATCH 30/31] mm, vmstat: print node-based stats in zoneinfo file Mel Gorman
2016-07-01 15:37 ` [PATCH 31/31] mm, vmstat: Remove zone and node double accounting by approximating retries Mel Gorman
2016-07-07 23:27 ` [PATCH 00/31] Move LRU page reclaim from zones to nodes v8 Dave Chinner
2016-07-08 9:52 ` Mel Gorman
2016-07-11 0:47 ` Dave Chinner
2016-07-11 9:02 ` Mel Gorman [this message]
2016-07-12 2:52 ` Dave Chinner
2016-07-01 20:01 Mel Gorman
2016-07-04 1:37 ` Minchan Kim
2016-07-04 4:34 ` Mel Gorman
2016-07-04 8:04 ` Minchan Kim
2016-07-04 9:55 ` Mel Gorman
2016-07-06 1:51 ` Minchan Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160711090224.GB9806@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).