* Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis [not found] <02ed01d1c47a$49fbfbc0$ddf3f340$@alibaba-inc.com> @ 2016-06-12 7:33 ` Hillf Danton 2016-06-14 14:47 ` Mel Gorman 0 siblings, 1 reply; 11+ messages in thread From: Hillf Danton @ 2016-06-12 7:33 UTC (permalink / raw) To: 'Mel Gorman'; +Cc: linux-kernel, linux-mm > @@ -3207,15 +3228,14 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) > sc.may_writepage = 1; > > /* > - * Now scan the zone in the dma->highmem direction, stopping > - * at the last zone which needs scanning. > - * > - * We do this because the page allocator works in the opposite > - * direction. This prevents the page allocator from allocating > - * pages behind kswapd's direction of progress, which would > - * cause too much scanning of the lower zones. > + * Continue scanning in the highmem->dma direction stopping at > + * the last zone which needs scanning. This may reclaim lowmem > + * pages that are not necessary for zone balancing but it > + * preserves LRU ordering. It is assumed that the bulk of > + * allocation requests can use arbitrary zones with the > + * possible exception of big highmem:lowmem configurations. > */ > - for (i = 0; i <= end_zone; i++) { > + for (i = end_zone; i >= end_zone; i--) { s/i >= end_zone;/i >= 0;/ ? > struct zone *zone = pgdat->node_zones + i; > > if (!populated_zone(zone)) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-12 7:33 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Hillf Danton @ 2016-06-14 14:47 ` Mel Gorman 0 siblings, 0 replies; 11+ messages in thread From: Mel Gorman @ 2016-06-14 14:47 UTC (permalink / raw) To: Hillf Danton; +Cc: linux-kernel, linux-mm On Sun, Jun 12, 2016 at 03:33:25PM +0800, Hillf Danton wrote: > > @@ -3207,15 +3228,14 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) > > sc.may_writepage = 1; > > > > /* > > - * Now scan the zone in the dma->highmem direction, stopping > > - * at the last zone which needs scanning. > > - * > > - * We do this because the page allocator works in the opposite > > - * direction. This prevents the page allocator from allocating > > - * pages behind kswapd's direction of progress, which would > > - * cause too much scanning of the lower zones. > > + * Continue scanning in the highmem->dma direction stopping at > > + * the last zone which needs scanning. This may reclaim lowmem > > + * pages that are not necessary for zone balancing but it > > + * preserves LRU ordering. It is assumed that the bulk of > > + * allocation requests can use arbitrary zones with the > > + * possible exception of big highmem:lowmem configurations. > > */ > > - for (i = 0; i <= end_zone; i++) { > > + for (i = end_zone; i >= end_zone; i--) { > > s/i >= end_zone;/i >= 0;/ ? > Yes although it's eliminated by "mm, vmscan: Make kswapd reclaim in terms of nodes" -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 00/27] Move LRU page reclaim from zones to nodes v7
@ 2016-06-21 14:15 Mel Gorman
2016-06-21 14:15 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman
0 siblings, 1 reply; 11+ messages in thread
From: Mel Gorman @ 2016-06-21 14:15 UTC (permalink / raw)
To: Andrew Morton, Linux-MM
Cc: Rik van Riel, Vlastimil Babka, Johannes Weiner, LKML, Mel Gorman
(sorry for resend, the previous attempt didn't go through fully for
some reason)
The bulk of the updates are in response to review from Vlastimil Babka
and received a lot more testing than v6.
Changelog since v6
o Correct reclaim_idx when direct reclaiming for memcg
o Also account LRU pages per zone for compaction/reclaim
o Add page_pgdat helper with more efficient lookup
o Init pgdat LRU lock only once
o Slight optimisation to wake_all_kswapds
o Always wake kcompactd when kswapd is going to sleep
o Rebase to mmotm as of June 15th, 2016
Changelog since v5
o Rebase and adjust to changes
Changelog since v4
o Rebase on top of v3 of page allocator optimisation series
Changelog since v3
o Rebase on top of the page allocator optimisation series
o Remove RFC tag
This is the latest version of a series that moves LRUs from the zones to
the node that is based upon 4.6-rc3 plus the page allocator optimisation
series. Conceptually, this is simple but there are a lot of details. Some
of the broad motivations for this are;
1. The residency of a page partially depends on what zone the page was
allocated from. This is partially combatted by the fair zone allocation
policy but that is a partial solution that introduces overhead in the
page allocator paths.
2. Currently, reclaim on node 0 behaves slightly different to node 1. For
example, direct reclaim scans in zonelist order and reclaims even if
the zone is over the high watermark regardless of the age of pages
in that LRU. Kswapd on the other hand starts reclaim on the highest
unbalanced zone. A difference in distribution of file/anon pages due
to when they were allocated results can result in a difference in
again. While the fair zone allocation policy mitigates some of the
problems here, the page reclaim results on a multi-zone node will
always be different to a single-zone node.
it was scheduled on as a result.
3. kswapd and the page allocator scan zones in the opposite order to
avoid interfering with each other but it's sensitive to timing. This
mitigates the page allocator using pages that were allocated very recently
in the ideal case but it's sensitive to timing. When kswapd is allocating
from lower zones then it's great but during the rebalancing of the highest
zone, the page allocator and kswapd interfere with each other. It's worse
if the highest zone is small and difficult to balance.
4. slab shrinkers are node-based which makes it harder to identify the exact
relationship between slab reclaim and LRU reclaim.
The reason we have zone-based reclaim is that we used to have
large highmem zones in common configurations and it was necessary
to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
less of a concern as machines with lots of memory will (or should) use
64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
rare. Machines that do use highmem should have relatively low highmem:lowmem
ratios than we worried about in the past.
Conceptually, moving to node LRUs should be easier to understand. The
page allocator plays fewer tricks to game reclaim and reclaim behaves
similarly on all nodes.
The series has been tested on a 16 core UMA machine and a 2-socket 48 core
NUMA machine. The UMA results are presented in most cases as the NUMA machine
behaved similarly.
pagealloc
---------
This is a microbenchmark that shows the benefit of removing the fair zone
allocation policy. It was tested uip to order-4 but only orders 0 and 1 are
shown as the other orders were comparable.
4.7.0-rc3 4.7.0-rc3
mmotm-20160615 nodelru-v7r17
Min total-odr0-1 485.00 ( 0.00%) 462.00 ( 4.74%)
Min total-odr0-2 354.00 ( 0.00%) 341.00 ( 3.67%)
Min total-odr0-4 285.00 ( 0.00%) 277.00 ( 2.81%)
Min total-odr0-8 249.00 ( 0.00%) 240.00 ( 3.61%)
Min total-odr0-16 230.00 ( 0.00%) 224.00 ( 2.61%)
Min total-odr0-32 222.00 ( 0.00%) 215.00 ( 3.15%)
Min total-odr0-64 216.00 ( 0.00%) 210.00 ( 2.78%)
Min total-odr0-128 214.00 ( 0.00%) 208.00 ( 2.80%)
Min total-odr0-256 248.00 ( 0.00%) 233.00 ( 6.05%)
Min total-odr0-512 277.00 ( 0.00%) 270.00 ( 2.53%)
Min total-odr0-1024 294.00 ( 0.00%) 284.00 ( 3.40%)
Min total-odr0-2048 308.00 ( 0.00%) 298.00 ( 3.25%)
Min total-odr0-4096 318.00 ( 0.00%) 307.00 ( 3.46%)
Min total-odr0-8192 322.00 ( 0.00%) 308.00 ( 4.35%)
Min total-odr0-16384 324.00 ( 0.00%) 309.00 ( 4.63%)
Min total-odr1-1 729.00 ( 0.00%) 686.00 ( 5.90%)
Min total-odr1-2 533.00 ( 0.00%) 520.00 ( 2.44%)
Min total-odr1-4 434.00 ( 0.00%) 415.00 ( 4.38%)
Min total-odr1-8 390.00 ( 0.00%) 364.00 ( 6.67%)
Min total-odr1-16 359.00 ( 0.00%) 335.00 ( 6.69%)
Min total-odr1-32 356.00 ( 0.00%) 327.00 ( 8.15%)
Min total-odr1-64 356.00 ( 0.00%) 321.00 ( 9.83%)
Min total-odr1-128 356.00 ( 0.00%) 333.00 ( 6.46%)
Min total-odr1-256 354.00 ( 0.00%) 337.00 ( 4.80%)
Min total-odr1-512 366.00 ( 0.00%) 340.00 ( 7.10%)
Min total-odr1-1024 373.00 ( 0.00%) 354.00 ( 5.09%)
Min total-odr1-2048 375.00 ( 0.00%) 354.00 ( 5.60%)
Min total-odr1-4096 374.00 ( 0.00%) 354.00 ( 5.35%)
Min total-odr1-8192 370.00 ( 0.00%) 355.00 ( 4.05%)
This shows a steady improvement throughout. The primary benefit is from
reduced system CPU usage which is obvious from the overall times;
4.7.0-rc3 4.7.0-rc3
mmotm-20160615 nodelru-v7
User 174.06 174.58
System 2656.78 2485.21
Elapsed 2885.07 2713.67
The vmstats also showed that the fair zone allocation policy was definitely
removed as can be seen here;
4.7.0-rc3 4.7.0-rc3
mmotm-20160615nodelru-v7r17
DMA32 allocs 28794408561 0
Normal allocs 48431969998 77226313470
Movable allocs 0 0
tiobench on ext4
----------------
tiobench is a benchmark that artifically benefits if old pages remain resident
while new pages get reclaimed. The fair zone allocation policy mitigates this
problem so pages age fairly. While the benchmark has problems, it is important
that tiobench performance remains constant as it implies that page aging
problems that the fair zone allocation policy fixes are not re-introduced.
4.7.0-rc3 4.7.0-rc3
mmotm-20160615 nodelru-v7r17
Min PotentialReadSpeed 90.24 ( 0.00%) 90.14 ( -0.11%)
Min SeqRead-MB/sec-1 80.63 ( 0.00%) 83.09 ( 3.05%)
Min SeqRead-MB/sec-2 71.91 ( 0.00%) 72.44 ( 0.74%)
Min SeqRead-MB/sec-4 75.20 ( 0.00%) 74.32 ( -1.17%)
Min SeqRead-MB/sec-8 65.30 ( 0.00%) 65.21 ( -0.14%)
Min SeqRead-MB/sec-16 62.62 ( 0.00%) 62.12 ( -0.80%)
Min RandRead-MB/sec-1 0.90 ( 0.00%) 0.94 ( 4.44%)
Min RandRead-MB/sec-2 0.96 ( 0.00%) 0.97 ( 1.04%)
Min RandRead-MB/sec-4 1.43 ( 0.00%) 1.41 ( -1.40%)
Min RandRead-MB/sec-8 1.67 ( 0.00%) 1.72 ( 2.99%)
Min RandRead-MB/sec-16 1.77 ( 0.00%) 1.86 ( 5.08%)
Min SeqWrite-MB/sec-1 78.12 ( 0.00%) 79.78 ( 2.12%)
Min SeqWrite-MB/sec-2 72.74 ( 0.00%) 73.23 ( 0.67%)
Min SeqWrite-MB/sec-4 79.40 ( 0.00%) 78.32 ( -1.36%)
Min SeqWrite-MB/sec-8 73.18 ( 0.00%) 71.40 ( -2.43%)
Min SeqWrite-MB/sec-16 75.82 ( 0.00%) 75.24 ( -0.76%)
Min RandWrite-MB/sec-1 1.18 ( 0.00%) 1.15 ( -2.54%)
Min RandWrite-MB/sec-2 1.05 ( 0.00%) 0.99 ( -5.71%)
Min RandWrite-MB/sec-4 1.00 ( 0.00%) 0.96 ( -4.00%)
Min RandWrite-MB/sec-8 0.91 ( 0.00%) 0.92 ( 1.10%)
Min RandWrite-MB/sec-16 0.92 ( 0.00%) 0.92 ( 0.00%)
This shows that the series has little or not impact on tiobench which is
desirable. It indicates that the fair zone allocation policy was removed
in a manner that didn't reintroduce one class of page aging bug. There
were only minor differences in overall reclaim activity
4.7.0-rc3 4.7.0-rc3
mmotm-20160615nodelru-v7r17
Minor Faults 640992 640721
Major Faults 728 623
Swap Ins 0 0
Swap Outs 0 0
DMA allocs 0 0
DMA32 allocs 46174282 44219717
Normal allocs 77949344 79858024
Movable allocs 0 0
Allocation stalls 38 76
Direct pages scanned 17463 34865
Kswapd pages scanned 93331163 93302388
Kswapd pages reclaimed 93328173 93299677
Direct pages reclaimed 17463 34865
Kswapd efficiency 99% 99%
Kswapd velocity 13729.855 13755.612
Direct efficiency 100% 100%
Direct velocity 2.569 5.140
Percentage direct scans 0% 0%
Page writes by reclaim 0 0
Page writes file 0 0
Page writes anon 0 0
Page reclaim immediate 54 36
kswapd activity was roughly comparable. There was slight differences
in direct reclaim activity but negligible in the context of the overall
workload (velocity of 5 pages per second with the patches applied, 2 pages
per second in the baseline kernel).
pgbench read-only large configuration on ext4
---------------------------------------------
pgbench is a database benchmark that can be sensitive to page reclaim
decisions. This also checks if removing the fair zone allocation policy
is safe
pgbench Transactions
4.7.0-rc3 4.7.0-rc3
mmotm-20160615 nodelru-v7r17
Hmean 1 191.00 ( 0.00%) 193.67 ( 1.40%)
Hmean 5 338.59 ( 0.00%) 336.99 ( -0.47%)
Hmean 12 374.03 ( 0.00%) 386.15 ( 3.24%)
Hmean 21 372.24 ( 0.00%) 372.02 ( -0.06%)
Hmean 30 383.98 ( 0.00%) 370.69 ( -3.46%)
Hmean 32 431.01 ( 0.00%) 438.47 ( 1.73%)
Negligible differences again. As with tiobench, overall reclaim activity
was comparable.
bonnie++ on ext4
----------------
No interesting performance difference, negligible differences on reclaim
stats.
paralleldd on ext4
------------------
This workload uses varying numbers of dd instances to read large amounts of
data from disk.
paralleldd
4.7.0-rc3 4.7.0-rc3
mmotm-20160615 nodelru-v7r17
Amean Elapsd-1 181.57 ( 0.00%) 179.63 ( 1.07%)
Amean Elapsd-3 188.29 ( 0.00%) 183.68 ( 2.45%)
Amean Elapsd-5 188.02 ( 0.00%) 181.73 ( 3.35%)
Amean Elapsd-7 186.07 ( 0.00%) 184.11 ( 1.05%)
Amean Elapsd-12 188.16 ( 0.00%) 183.51 ( 2.47%)
Amean Elapsd-16 189.03 ( 0.00%) 181.27 ( 4.10%)
4.7.0-rc3 4.7.0-rc3
mmotm-20160615nodelru-v7r17
User 1439.23 1433.37
System 8332.31 8216.01
Elapsed 3619.80 3532.69
There is a slight gain in performance, some of which is from the reduced system
CPU usage. There areminor differences in reclaim activity but nothing significant
4.7.0-rc3 4.7.0-rc3
mmotm-20160615nodelru-v7r17
Minor Faults 362486 358215
Major Faults 1143 1113
Swap Ins 26 0
Swap Outs 2920 482
DMA allocs 0 0
DMA32 allocs 31568814 28598887
Normal allocs 46539922 49514444
Movable allocs 0 0
Allocation stalls 0 0
Direct pages scanned 0 0
Kswapd pages scanned 40886878 40849710
Kswapd pages reclaimed 40869923 40835207
Direct pages reclaimed 0 0
Kswapd efficiency 99% 99%
Kswapd velocity 11295.342 11563.344
Direct efficiency 100% 100%
Direct velocity 0.000 0.000
Slabs scanned 131673 126099
Direct inode steals 57 60
Kswapd inode steals 762 18
It basically shows that kswapd was active at roughly the same rate in
both kernels. There was also comparable slab scanning activity and direct
reclaim was avoided in both cases. There appears to be a large difference
in numbers of inodes reclaimed but the workload has few active inodes and
is likely a timing artifact. It's interesting to note that the node-lru
did not swap in any pages but given the low swap activity, it's unlikely
to be significant.
stutter
-------
stutter simulates a simple workload. One part uses a lot of anonymous
memory, a second measures mmap latency and a third copies a large file.
The primary metric is checking for mmap latency.
stutter
4.7.0-rc3 4.7.0-rc3
mmotm-20160615 nodelru-v7r17
Min mmap 16.8422 ( 0.00%) 15.9821 ( 5.11%)
1st-qrtle mmap 57.8709 ( 0.00%) 58.0794 ( -0.36%)
2nd-qrtle mmap 58.4335 ( 0.00%) 59.4286 ( -1.70%)
3rd-qrtle mmap 58.6957 ( 0.00%) 59.6862 ( -1.69%)
Max-90% mmap 58.9388 ( 0.00%) 59.8759 ( -1.59%)
Max-93% mmap 59.0505 ( 0.00%) 59.9333 ( -1.50%)
Max-95% mmap 59.1877 ( 0.00%) 59.9844 ( -1.35%)
Max-99% mmap 60.3237 ( 0.00%) 60.2337 ( 0.15%)
Max mmap 285.6454 ( 0.00%) 135.6006 ( 52.53%)
Mean mmap 57.8366 ( 0.00%) 58.4884 ( -1.13%)
This shows that there is a slight impact on mmap latency but that
the worst-case outlier is much improved. As the problem with this
benchmark used to be that the kernel stalled for minutes, this
difference is negligible.
Some of the vmstats are interesting
4.7.0-rc3 4.7.0-rc3
mmotm-20160615nodelru-v7r17
Swap Ins 58 42
Swap Outs 0 0
Allocation stalls 16 0
Direct pages scanned 1374 0
Kswapd pages scanned 42454910 41782544
Kswapd pages reclaimed 41571035 41781833
Direct pages reclaimed 1167 0
Kswapd efficiency 97% 99%
Kswapd velocity 14774.479 14223.796
Direct efficiency 84% 100%
Direct velocity 0.478 0.000
Percentage direct scans 0% 0%
Page writes by reclaim 696918 0
Page writes file 696918 0
Page writes anon 0 0
Page reclaim immediate 2940 137
Sector Reads 81644424 81699544
Sector Writes 99193620 98862160
Page rescued immediate 0 0
Slabs scanned 1279838 22640
kswapd and direct reclaim activity are similar but the node LRU series
did not attempt to trigger any page writes from reclaim context.
This series is not without its hazards. There are at least three areas
that I'm concerned with even though I could not reproduce any problems in
that area.
1. Reclaim/compaction is going to be affected because the amount of reclaim is
no longer targetted at a specific zone. Compaction works on a per-zone basis
so there is no guarantee that reclaiming a few THP's worth page pages will
have a positive impact on compaction success rates.
2. The Slab/LRU reclaim ratio is affected because the frequency the shrinkers
are called is now different. This may or may not be a problem but if it
is, it'll be because shrinkers are not called enough and some balancing
is required.
3. The anon/file reclaim ratio may be affected. Pages about to be dirtied are
distributed between zones and the fair zone allocation policy used to do
something very similar for anon. The distribution is now different but not
necessarily in any way that matters but it's still worth bearing in mind.
Documentation/cgroup-v1/memcg_test.txt | 4 +-
Documentation/cgroup-v1/memory.txt | 4 +-
arch/s390/appldata/appldata_mem.c | 2 +-
arch/tile/mm/pgtable.c | 18 +-
drivers/base/node.c | 73 +--
drivers/staging/android/lowmemorykiller.c | 12 +-
fs/fs-writeback.c | 4 +-
fs/fuse/file.c | 8 +-
fs/nfs/internal.h | 2 +-
fs/nfs/write.c | 2 +-
fs/proc/meminfo.c | 14 +-
include/linux/backing-dev.h | 2 +-
include/linux/memcontrol.h | 32 +-
include/linux/mm.h | 5 +
include/linux/mm_inline.h | 21 +-
include/linux/mm_types.h | 2 +-
include/linux/mmzone.h | 158 +++---
include/linux/swap.h | 23 +-
include/linux/topology.h | 2 +-
include/linux/vm_event_item.h | 14 +-
include/linux/vmstat.h | 111 +++-
include/linux/writeback.h | 2 +-
include/trace/events/vmscan.h | 63 ++-
include/trace/events/writeback.h | 10 +-
kernel/power/snapshot.c | 10 +-
kernel/sysctl.c | 4 +-
mm/backing-dev.c | 15 +-
mm/compaction.c | 28 +-
mm/filemap.c | 14 +-
mm/huge_memory.c | 33 +-
mm/internal.h | 11 +-
mm/memcontrol.c | 246 ++++----
mm/memory-failure.c | 4 +-
mm/memory_hotplug.c | 7 +-
mm/mempolicy.c | 2 +-
mm/migrate.c | 35 +-
mm/mlock.c | 12 +-
mm/page-writeback.c | 124 ++--
mm/page_alloc.c | 268 ++++-----
mm/page_idle.c | 4 +-
mm/rmap.c | 14 +-
mm/shmem.c | 12 +-
mm/swap.c | 66 +--
mm/swap_state.c | 4 +-
mm/util.c | 4 +-
mm/vmscan.c | 901 +++++++++++++++---------------
mm/vmstat.c | 376 ++++++++++---
mm/workingset.c | 54 +-
48 files changed, 1573 insertions(+), 1263 deletions(-)
--
2.6.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-21 14:15 [PATCH 00/27] Move LRU page reclaim from zones to nodes v7 Mel Gorman @ 2016-06-21 14:15 ` Mel Gorman 2016-06-22 14:04 ` Vlastimil Babka 0 siblings, 1 reply; 11+ messages in thread From: Mel Gorman @ 2016-06-21 14:15 UTC (permalink / raw) To: Andrew Morton, Linux-MM Cc: Rik van Riel, Vlastimil Babka, Johannes Weiner, LKML, Mel Gorman This patch makes reclaim decisions on a per-node basis. A reclaimer knows what zone is required by the allocation request and skips pages from higher zones. In many cases this will be ok because it's a GFP_HIGHMEM request of some description. On 64-bit, ZONE_DMA32 requests will cause some problems but 32-bit devices on 64-bit platforms are increasingly rare. Historically it would have been a major problem on 32-bit with big Highmem:Lowmem ratios but such configurations are also now rare and even where they exist, they are not encouraged. If it really becomes a problem, it'll manifest as very low reclaim efficiencies. Signed-off-by: Mel Gorman <mgorman@techsingularity.net> --- mm/vmscan.c | 78 +++++++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 53 insertions(+), 25 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 39cd6375f54e..7d5bad437809 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -84,6 +84,9 @@ struct scan_control { /* Scan (total_size >> priority) pages at once */ int priority; + /* The highest zone to isolate pages for reclaim from */ + enum zone_type reclaim_idx; + unsigned int may_writepage:1; /* Can mapped pages be reclaimed? */ @@ -1386,6 +1389,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, unsigned long nr_taken = 0; unsigned long nr_zone_taken[MAX_NR_ZONES] = { 0 }; unsigned long scan, nr_pages; + LIST_HEAD(pages_skipped); for (scan = 0; scan < nr_to_scan && nr_taken < nr_to_scan && !list_empty(src); scan++) { @@ -1396,6 +1400,11 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, VM_BUG_ON_PAGE(!PageLRU(page), page); + if (page_zonenum(page) > sc->reclaim_idx) { + list_move(&page->lru, &pages_skipped); + continue; + } + switch (__isolate_lru_page(page, mode)) { case 0: nr_pages = hpage_nr_pages(page); @@ -1414,6 +1423,15 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, } } + /* + * Splice any skipped pages to the start of the LRU list. Note that + * this disrupts the LRU order when reclaiming for lower zones but + * we cannot splice to the tail. If we did then the SWAP_CLUSTER_MAX + * scanning would soon rescan the same pages to skip and put the + * system at risk of premature OOM. + */ + if (!list_empty(&pages_skipped)) + list_splice(&pages_skipped, src); *nr_scanned = scan; trace_mm_vmscan_lru_isolate(sc->order, nr_to_scan, scan, nr_taken, mode, is_file_lru(lru)); @@ -1583,7 +1601,7 @@ static int current_may_throttle(void) } /* - * shrink_inactive_list() is a helper for shrink_zone(). It returns the number + * shrink_inactive_list() is a helper for shrink_node(). It returns the number * of reclaimed pages */ static noinline_for_stack unsigned long @@ -2395,12 +2413,13 @@ static inline bool should_continue_reclaim(struct zone *zone, } } -static bool shrink_zone(struct zone *zone, struct scan_control *sc, - bool is_classzone) +static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc, + enum zone_type classzone_idx) { struct reclaim_state *reclaim_state = current->reclaim_state; unsigned long nr_reclaimed, nr_scanned; bool reclaimable = false; + struct zone *zone = &pgdat->node_zones[classzone_idx]; do { struct mem_cgroup *root = sc->target_mem_cgroup; @@ -2432,7 +2451,7 @@ static bool shrink_zone(struct zone *zone, struct scan_control *sc, shrink_zone_memcg(zone, memcg, sc, &lru_pages); zone_lru_pages += lru_pages; - if (memcg && is_classzone) + if (!global_reclaim(sc) && sc->reclaim_idx == classzone_idx) shrink_slab(sc->gfp_mask, zone_to_nid(zone), memcg, sc->nr_scanned - scanned, lru_pages); @@ -2463,7 +2482,7 @@ static bool shrink_zone(struct zone *zone, struct scan_control *sc, * Shrink the slab caches in the same proportion that * the eligible LRU pages were scanned. */ - if (global_reclaim(sc) && is_classzone) + if (global_reclaim(sc) && sc->reclaim_idx == classzone_idx) shrink_slab(sc->gfp_mask, zone_to_nid(zone), NULL, sc->nr_scanned - nr_scanned, zone_lru_pages); @@ -2540,14 +2559,14 @@ static inline bool compaction_ready(struct zone *zone, int order, int classzone_ * If a zone is deemed to be full of pinned pages then just give it a light * scan then give up on it. */ -static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) +static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc, + enum zone_type classzone_idx) { struct zoneref *z; struct zone *zone; unsigned long nr_soft_reclaimed; unsigned long nr_soft_scanned; gfp_t orig_mask; - enum zone_type requested_highidx = gfp_zone(sc->gfp_mask); /* * If the number of buffer_heads in the machine exceeds the maximum @@ -2560,15 +2579,20 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) for_each_zone_zonelist_nodemask(zone, z, zonelist, gfp_zone(sc->gfp_mask), sc->nodemask) { - enum zone_type classzone_idx; - if (!populated_zone(zone)) continue; - classzone_idx = requested_highidx; + /* + * Note that reclaim_idx does not change as it is the highest + * zone reclaimed from which for empty zones is a no-op but + * classzone_idx is used by shrink_node to test if the slabs + * should be shrunk on a given node. + */ while (!populated_zone(zone->zone_pgdat->node_zones + - classzone_idx)) + classzone_idx)) { classzone_idx--; + continue; + } /* * Take care memory controller reclaiming has small influence @@ -2594,8 +2618,8 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) */ if (IS_ENABLED(CONFIG_COMPACTION) && sc->order > PAGE_ALLOC_COSTLY_ORDER && - zonelist_zone_idx(z) <= requested_highidx && - compaction_ready(zone, sc->order, requested_highidx)) { + zonelist_zone_idx(z) <= classzone_idx && + compaction_ready(zone, sc->order, classzone_idx)) { sc->compaction_ready = true; continue; } @@ -2615,7 +2639,7 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) /* need some check for avoid more shrink_zone() */ } - shrink_zone(zone, sc, zone_idx(zone) == classzone_idx); + shrink_node(zone->zone_pgdat, sc, classzone_idx); } /* @@ -2647,6 +2671,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, int initial_priority = sc->priority; unsigned long total_scanned = 0; unsigned long writeback_threshold; + enum zone_type classzone_idx = sc->reclaim_idx; retry: delayacct_freepages_start(); @@ -2657,7 +2682,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, vmpressure_prio(sc->gfp_mask, sc->target_mem_cgroup, sc->priority); sc->nr_scanned = 0; - shrink_zones(zonelist, sc); + shrink_zones(zonelist, sc, classzone_idx); total_scanned += sc->nr_scanned; if (sc->nr_reclaimed >= sc->nr_to_reclaim) @@ -2841,6 +2866,7 @@ unsigned long try_to_free_pages(struct zonelist *zonelist, int order, struct scan_control sc = { .nr_to_reclaim = SWAP_CLUSTER_MAX, .gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)), + .reclaim_idx = gfp_zone(gfp_mask), .order = order, .nodemask = nodemask, .priority = DEF_PRIORITY, @@ -3112,7 +3138,7 @@ static bool kswapd_shrink_zone(struct zone *zone, balance_gap, classzone_idx)) return true; - shrink_zone(zone, sc, zone_idx(zone) == classzone_idx); + shrink_node(zone->zone_pgdat, sc, classzone_idx); /* TODO: ANOMALY */ clear_bit(PGDAT_WRITEBACK, &pgdat->flags); @@ -3161,6 +3187,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) unsigned long nr_soft_scanned; struct scan_control sc = { .gfp_mask = GFP_KERNEL, + .reclaim_idx = MAX_NR_ZONES - 1, .order = order, .priority = DEF_PRIORITY, .may_writepage = !laptop_mode, @@ -3231,15 +3258,14 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) sc.may_writepage = 1; /* - * Now scan the zone in the dma->highmem direction, stopping - * at the last zone which needs scanning. - * - * We do this because the page allocator works in the opposite - * direction. This prevents the page allocator from allocating - * pages behind kswapd's direction of progress, which would - * cause too much scanning of the lower zones. + * Continue scanning in the highmem->dma direction stopping at + * the last zone which needs scanning. This may reclaim lowmem + * pages that are not necessary for zone balancing but it + * preserves LRU ordering. It is assumed that the bulk of + * allocation requests can use arbitrary zones with the + * possible exception of big highmem:lowmem configurations. */ - for (i = 0; i <= end_zone; i++) { + for (i = end_zone; i >= 0; i--) { struct zone *zone = pgdat->node_zones + i; if (!populated_zone(zone)) @@ -3250,6 +3276,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) continue; sc.nr_scanned = 0; + sc.reclaim_idx = i; nr_soft_scanned = 0; /* @@ -3698,6 +3725,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order) .may_writepage = !!(zone_reclaim_mode & RECLAIM_WRITE), .may_unmap = !!(zone_reclaim_mode & RECLAIM_UNMAP), .may_swap = 1, + .reclaim_idx = zone_idx(zone), }; cond_resched(); @@ -3717,7 +3745,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order) * priorities until we have enough memory freed. */ do { - shrink_zone(zone, &sc, true); + shrink_node(zone->zone_pgdat, &sc, zone_idx(zone)); } while (sc.nr_reclaimed < nr_pages && --sc.priority >= 0); } -- 2.6.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-21 14:15 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman @ 2016-06-22 14:04 ` Vlastimil Babka 2016-06-22 16:00 ` Vlastimil Babka 2016-06-23 10:58 ` Mel Gorman 0 siblings, 2 replies; 11+ messages in thread From: Vlastimil Babka @ 2016-06-22 14:04 UTC (permalink / raw) To: Mel Gorman, Andrew Morton, Linux-MM; +Cc: Rik van Riel, Johannes Weiner, LKML On 06/21/2016 04:15 PM, Mel Gorman wrote: > This patch makes reclaim decisions on a per-node basis. A reclaimer knows > what zone is required by the allocation request and skips pages from > higher zones. In many cases this will be ok because it's a GFP_HIGHMEM > request of some description. On 64-bit, ZONE_DMA32 requests will cause > some problems but 32-bit devices on 64-bit platforms are increasingly > rare. Historically it would have been a major problem on 32-bit with big > Highmem:Lowmem ratios but such configurations are also now rare and even > where they exist, they are not encouraged. If it really becomes a problem, > it'll manifest as very low reclaim efficiencies. > > Signed-off-by: Mel Gorman <mgorman@techsingularity.net> [...] > @@ -2540,14 +2559,14 @@ static inline bool compaction_ready(struct zone *zone, int order, int classzone_ > * If a zone is deemed to be full of pinned pages then just give it a light > * scan then give up on it. > */ > -static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > +static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc, > + enum zone_type classzone_idx) > { > struct zoneref *z; > struct zone *zone; > unsigned long nr_soft_reclaimed; > unsigned long nr_soft_scanned; > gfp_t orig_mask; > - enum zone_type requested_highidx = gfp_zone(sc->gfp_mask); > > /* > * If the number of buffer_heads in the machine exceeds the maximum > @@ -2560,15 +2579,20 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > > for_each_zone_zonelist_nodemask(zone, z, zonelist, > gfp_zone(sc->gfp_mask), sc->nodemask) { Using sc->reclaim_idx could be faster/nicer here than gfp_zone()? Although after "mm, vmscan: Update classzone_idx if buffer_heads_over_limit" there would need to be a variable for the highmem adjusted value - maybe reuse "requested_highidx"? Not important though. > - enum zone_type classzone_idx; > - > if (!populated_zone(zone)) > continue; > > - classzone_idx = requested_highidx; > + /* > + * Note that reclaim_idx does not change as it is the highest > + * zone reclaimed from which for empty zones is a no-op but > + * classzone_idx is used by shrink_node to test if the slabs > + * should be shrunk on a given node. > + */ > while (!populated_zone(zone->zone_pgdat->node_zones + > - classzone_idx)) > + classzone_idx)) { > classzone_idx--; > + continue; > + } > > /* > * Take care memory controller reclaiming has small influence > @@ -2594,8 +2618,8 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > */ > if (IS_ENABLED(CONFIG_COMPACTION) && > sc->order > PAGE_ALLOC_COSTLY_ORDER && > - zonelist_zone_idx(z) <= requested_highidx && > - compaction_ready(zone, sc->order, requested_highidx)) { > + zonelist_zone_idx(z) <= classzone_idx && > + compaction_ready(zone, sc->order, classzone_idx)) { > sc->compaction_ready = true; > continue; > } > @@ -2615,7 +2639,7 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > /* need some check for avoid more shrink_zone() */ > } > > - shrink_zone(zone, sc, zone_idx(zone) == classzone_idx); > + shrink_node(zone->zone_pgdat, sc, classzone_idx); > } > > /* > @@ -2647,6 +2671,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, > int initial_priority = sc->priority; > unsigned long total_scanned = 0; > unsigned long writeback_threshold; > + enum zone_type classzone_idx = sc->reclaim_idx; Hmm, try_to_free_mem_cgroup_pages() seems to call this with sc->reclaim_idx not explicitly inirialized (e.g. 0). And shrink_all_memory() as well. I probably didn't check them in v6 and pointed out only try_to_free_pages() (which is now OK), sorry. > retry: > delayacct_freepages_start(); > > @@ -2657,7 +2682,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, > vmpressure_prio(sc->gfp_mask, sc->target_mem_cgroup, > sc->priority); > sc->nr_scanned = 0; > - shrink_zones(zonelist, sc); > + shrink_zones(zonelist, sc, classzone_idx); Looks like classzone_idx here is only used here to pass to shrink_zones() unchanged, which means it can just use it directly without a new param? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-22 14:04 ` Vlastimil Babka @ 2016-06-22 16:00 ` Vlastimil Babka 2016-06-23 11:07 ` Mel Gorman 2016-06-23 10:58 ` Mel Gorman 1 sibling, 1 reply; 11+ messages in thread From: Vlastimil Babka @ 2016-06-22 16:00 UTC (permalink / raw) To: Mel Gorman, Andrew Morton, Linux-MM Cc: Rik van Riel, Johannes Weiner, LKML, Michal Hocko On 06/22/2016 04:04 PM, Vlastimil Babka wrote: > On 06/21/2016 04:15 PM, Mel Gorman wrote: >> This patch makes reclaim decisions on a per-node basis. A reclaimer knows >> what zone is required by the allocation request and skips pages from >> higher zones. In many cases this will be ok because it's a GFP_HIGHMEM >> request of some description. On 64-bit, ZONE_DMA32 requests will cause >> some problems but 32-bit devices on 64-bit platforms are increasingly >> rare. Historically it would have been a major problem on 32-bit with big >> Highmem:Lowmem ratios but such configurations are also now rare and even >> where they exist, they are not encouraged. If it really becomes a problem, >> it'll manifest as very low reclaim efficiencies. >> >> Signed-off-by: Mel Gorman <mgorman@techsingularity.net> > > [...] > >> @@ -2540,14 +2559,14 @@ static inline bool compaction_ready(struct zone *zone, int order, int classzone_ >> * If a zone is deemed to be full of pinned pages then just give it a light >> * scan then give up on it. >> */ >> -static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) >> +static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc, >> + enum zone_type classzone_idx) >> { >> struct zoneref *z; >> struct zone *zone; >> unsigned long nr_soft_reclaimed; >> unsigned long nr_soft_scanned; >> gfp_t orig_mask; >> - enum zone_type requested_highidx = gfp_zone(sc->gfp_mask); >> >> /* >> * If the number of buffer_heads in the machine exceeds the maximum >> @@ -2560,15 +2579,20 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) >> >> for_each_zone_zonelist_nodemask(zone, z, zonelist, >> gfp_zone(sc->gfp_mask), sc->nodemask) { > > Using sc->reclaim_idx could be faster/nicer here than gfp_zone()? > Although after "mm, vmscan: Update classzone_idx if buffer_heads_over_limit" > there would need to be a variable for the highmem adjusted value - maybe reuse > "requested_highidx"? Not important though. > >> - enum zone_type classzone_idx; >> - >> if (!populated_zone(zone)) >> continue; >> >> - classzone_idx = requested_highidx; >> + /* >> + * Note that reclaim_idx does not change as it is the highest >> + * zone reclaimed from which for empty zones is a no-op but >> + * classzone_idx is used by shrink_node to test if the slabs >> + * should be shrunk on a given node. >> + */ >> while (!populated_zone(zone->zone_pgdat->node_zones + >> - classzone_idx)) >> + classzone_idx)) { >> classzone_idx--; >> + continue; Oh and Michal's comment on Patch 20 made me realize that my objection to v6 about possible underflow of sc->reclaim_idx and classzone_idx seems to still apply here for classzone_idx? Updated example: Normal zone allocation. A small node 0 without Normal zone will get us classzone_idx == dma32. Node 1 next in zonelist won't have dma/dma32 zones so we won't see node_zones + classzone_idx populated, and the while loop will lead to underflow of classzone_idx. I may be missing something, but I don't really see another way around it than resetting classzone_idx to sc->reclaim_idx before the while loop. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-22 16:00 ` Vlastimil Babka @ 2016-06-23 11:07 ` Mel Gorman 2016-06-23 11:13 ` Michal Hocko 0 siblings, 1 reply; 11+ messages in thread From: Mel Gorman @ 2016-06-23 11:07 UTC (permalink / raw) To: Vlastimil Babka Cc: Andrew Morton, Linux-MM, Rik van Riel, Johannes Weiner, LKML, Michal Hocko On Wed, Jun 22, 2016 at 06:00:12PM +0200, Vlastimil Babka wrote: > >>- enum zone_type classzone_idx; > >>- > >> if (!populated_zone(zone)) > >> continue; > >> > >>- classzone_idx = requested_highidx; > >>+ /* > >>+ * Note that reclaim_idx does not change as it is the highest > >>+ * zone reclaimed from which for empty zones is a no-op but > >>+ * classzone_idx is used by shrink_node to test if the slabs > >>+ * should be shrunk on a given node. > >>+ */ > >> while (!populated_zone(zone->zone_pgdat->node_zones + > >>- classzone_idx)) > >>+ classzone_idx)) { > >> classzone_idx--; > >>+ continue; > > Oh and Michal's comment on Patch 20 made me realize that my objection to v6 > about possible underflow of sc->reclaim_idx and classzone_idx seems to still > apply here for classzone_idx? Potentially. The relevant code now looks like this classzone_idx = sc->reclaim_idx; while (!populated_zone(zone->zone_pgdat->node_zones + classzone_idx)) classzone_idx--; -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-23 11:07 ` Mel Gorman @ 2016-06-23 11:13 ` Michal Hocko 0 siblings, 0 replies; 11+ messages in thread From: Michal Hocko @ 2016-06-23 11:13 UTC (permalink / raw) To: Mel Gorman Cc: Vlastimil Babka, Andrew Morton, Linux-MM, Rik van Riel, Johannes Weiner, LKML On Thu 23-06-16 12:07:28, Mel Gorman wrote: > On Wed, Jun 22, 2016 at 06:00:12PM +0200, Vlastimil Babka wrote: > > >>- enum zone_type classzone_idx; > > >>- > > >> if (!populated_zone(zone)) > > >> continue; > > >> > > >>- classzone_idx = requested_highidx; > > >>+ /* > > >>+ * Note that reclaim_idx does not change as it is the highest > > >>+ * zone reclaimed from which for empty zones is a no-op but > > >>+ * classzone_idx is used by shrink_node to test if the slabs > > >>+ * should be shrunk on a given node. > > >>+ */ > > >> while (!populated_zone(zone->zone_pgdat->node_zones + > > >>- classzone_idx)) > > >>+ classzone_idx)) { > > >> classzone_idx--; > > >>+ continue; > > > > Oh and Michal's comment on Patch 20 made me realize that my objection to v6 > > about possible underflow of sc->reclaim_idx and classzone_idx seems to still > > apply here for classzone_idx? > > Potentially. The relevant code now looks like this > > classzone_idx = sc->reclaim_idx; > while (!populated_zone(zone->zone_pgdat->node_zones + > classzone_idx)) > classzone_idx--; Yes that makes much more sense to me. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-22 14:04 ` Vlastimil Babka 2016-06-22 16:00 ` Vlastimil Babka @ 2016-06-23 10:58 ` Mel Gorman 1 sibling, 0 replies; 11+ messages in thread From: Mel Gorman @ 2016-06-23 10:58 UTC (permalink / raw) To: Vlastimil Babka Cc: Andrew Morton, Linux-MM, Rik van Riel, Johannes Weiner, LKML On Wed, Jun 22, 2016 at 04:04:34PM +0200, Vlastimil Babka wrote: > >-static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > >+static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc, > >+ enum zone_type classzone_idx) > > { > > struct zoneref *z; > > struct zone *zone; > > unsigned long nr_soft_reclaimed; > > unsigned long nr_soft_scanned; > > gfp_t orig_mask; > >- enum zone_type requested_highidx = gfp_zone(sc->gfp_mask); > > > > /* > > * If the number of buffer_heads in the machine exceeds the maximum > >@@ -2560,15 +2579,20 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > > > > for_each_zone_zonelist_nodemask(zone, z, zonelist, > > gfp_zone(sc->gfp_mask), sc->nodemask) { > > Using sc->reclaim_idx could be faster/nicer here than gfp_zone()? Yes, then the reclaim_idx and classzone_idx needs to be updated if buffer_heads_over_limit in the check above but that is better anyway. > Although after "mm, vmscan: Update classzone_idx if buffer_heads_over_limit" > there would need to be a variable for the highmem adjusted value - maybe > reuse "requested_highidx"? Not important though. > I think it's ok in the buffer_heads_over_limit case to reclaim from more zones than requested. It may require another pass through do_try_to_free_pages if a low zone was not reclaimed and required by the caller but that's ok and expected if there are too many buffer_heads. > >- enum zone_type classzone_idx; > >- > > if (!populated_zone(zone)) > > continue; > > > >- classzone_idx = requested_highidx; > >+ /* > >+ * Note that reclaim_idx does not change as it is the highest > >+ * zone reclaimed from which for empty zones is a no-op but > >+ * classzone_idx is used by shrink_node to test if the slabs > >+ * should be shrunk on a given node. > >+ */ > > while (!populated_zone(zone->zone_pgdat->node_zones + > >- classzone_idx)) > >+ classzone_idx)) { > > classzone_idx--; > >+ continue; > >+ } > > > > /* > > * Take care memory controller reclaiming has small influence > >@@ -2594,8 +2618,8 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > > */ > > if (IS_ENABLED(CONFIG_COMPACTION) && > > sc->order > PAGE_ALLOC_COSTLY_ORDER && > >- zonelist_zone_idx(z) <= requested_highidx && > >- compaction_ready(zone, sc->order, requested_highidx)) { > >+ zonelist_zone_idx(z) <= classzone_idx && > >+ compaction_ready(zone, sc->order, classzone_idx)) { > > sc->compaction_ready = true; > > continue; > > } > >@@ -2615,7 +2639,7 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > > /* need some check for avoid more shrink_zone() */ > > } > > > >- shrink_zone(zone, sc, zone_idx(zone) == classzone_idx); > >+ shrink_node(zone->zone_pgdat, sc, classzone_idx); > > } > > > > /* > >@@ -2647,6 +2671,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, > > int initial_priority = sc->priority; > > unsigned long total_scanned = 0; > > unsigned long writeback_threshold; > >+ enum zone_type classzone_idx = sc->reclaim_idx; > > Hmm, try_to_free_mem_cgroup_pages() seems to call this with sc->reclaim_idx > not explicitly inirialized (e.g. 0). And shrink_all_memory() as well. I > probably didn't check them in v6 and pointed out only try_to_free_pages() > (which is now OK), sorry. > That gets fixed in "mm, memcg: move memcg limit enforcement from zones to nodes" but I can move the hunk to this patch to make bisection a little easier. > > retry: > > delayacct_freepages_start(); > > > >@@ -2657,7 +2682,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, > > vmpressure_prio(sc->gfp_mask, sc->target_mem_cgroup, > > sc->priority); > > sc->nr_scanned = 0; > >- shrink_zones(zonelist, sc); > >+ shrink_zones(zonelist, sc, classzone_idx); > > Looks like classzone_idx here is only used here to pass to shrink_zones() > unchanged, which means it can just use it directly without a new param? > Yes -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 00/27] Move LRU page reclaim from zones to nodes v6
@ 2016-06-09 18:04 Mel Gorman
2016-06-09 18:04 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman
0 siblings, 1 reply; 11+ messages in thread
From: Mel Gorman @ 2016-06-09 18:04 UTC (permalink / raw)
To: Andrew Morton, Linux-MM
Cc: Rik van Riel, Vlastimil Babka, Johannes Weiner, LKML, Mel Gorman
This is only lightly tested as I've had stability problems during boot
that have nothing to do with the series. It's based on mmots as of June
6th. Very little has changed with the big exception of "mm, vmscan:
Move LRU lists to node" because it had to adapt to per-zone changes in
should_reclaim_retry and compaction_zonelist_suitable.
Changelog since v5
o Rebase and adjust to changes
Changelog since v4
o Rebase on top of v3 of page allocator optimisation series
Changelog since v3
o Rebase on top of the page allocator optimisation series
o Remove RFC tag
This is the latest version of a series that moves LRUs from the zones to
the node that is based upon 4.6-rc3 plus the page allocator optimisation
series. Conceptually, this is simple but there are a lot of details. Some
of the broad motivations for this are;
1. The residency of a page partially depends on what zone the page was
allocated from. This is partially combatted by the fair zone allocation
policy but that is a partial solution that introduces overhead in the
page allocator paths.
2. Currently, reclaim on node 0 behaves slightly different to node 1. For
example, direct reclaim scans in zonelist order and reclaims even if
the zone is over the high watermark regardless of the age of pages
in that LRU. Kswapd on the other hand starts reclaim on the highest
unbalanced zone. A difference in distribution of file/anon pages due
to when they were allocated results can result in a difference in
again. While the fair zone allocation policy mitigates some of the
problems here, the page reclaim results on a multi-zone node will
always be different to a single-zone node.
it was scheduled on as a result.
3. kswapd and the page allocator scan zones in the opposite order to
avoid interfering with each other but it's sensitive to timing. This
mitigates the page allocator using pages that were allocated very recently
in the ideal case but it's sensitive to timing. When kswapd is allocating
from lower zones then it's great but during the rebalancing of the highest
zone, the page allocator and kswapd interfere with each other. It's worse
if the highest zone is small and difficult to balance.
4. slab shrinkers are node-based which makes it harder to identify the exact
relationship between slab reclaim and LRU reclaim.
The reason we have zone-based reclaim is that we used to have
large highmem zones in common configurations and it was necessary
to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
less of a concern as machines with lots of memory will (or should) use
64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
rare. Machines that do use highmem should have relatively low highmem:lowmem
ratios than we worried about in the past.
Conceptually, moving to node LRUs should be easier to understand. The
page allocator plays fewer tricks to game reclaim and reclaim behaves
similarly on all nodes.
The series got basic testing this time on a UMA machine. The page allocator
microbenchmark highlights the gain from removing the fair zone allocation
policy
4.7.0-rc2 4.7.0-rc2
mmotm-20160606 nodelru-v6r2
Min total-odr0-1 500.00 ( 0.00%) 475.00 ( 5.00%)
Min total-odr0-2 358.00 ( 0.00%) 343.00 ( 4.19%)
Min total-odr0-4 292.00 ( 0.00%) 279.00 ( 4.45%)
Min total-odr0-8 253.00 ( 0.00%) 242.00 ( 4.35%)
Min total-odr0-16 275.00 ( 0.00%) 226.00 ( 17.82%)
Min total-odr0-32 225.00 ( 0.00%) 215.00 ( 4.44%)
Min total-odr0-64 219.00 ( 0.00%) 210.00 ( 4.11%)
Min total-odr0-128 216.00 ( 0.00%) 207.00 ( 4.17%)
Min total-odr0-256 243.00 ( 0.00%) 246.00 ( -1.23%)
Min total-odr0-512 276.00 ( 0.00%) 265.00 ( 3.99%)
Min total-odr0-1024 290.00 ( 0.00%) 287.00 ( 1.03%)
Min total-odr0-2048 303.00 ( 0.00%) 296.00 ( 2.31%)
Min total-odr0-4096 312.00 ( 0.00%) 310.00 ( 0.64%)
Min total-odr0-8192 320.00 ( 0.00%) 308.00 ( 3.75%)
Min total-odr0-16384 320.00 ( 0.00%) 308.00 ( 3.75%)
Min total-odr1-1 737.00 ( 0.00%) 707.00 ( 4.07%)
Min total-odr1-2 547.00 ( 0.00%) 521.00 ( 4.75%)
Min total-odr1-4 620.00 ( 0.00%) 418.00 ( 32.58%)
Min total-odr1-8 386.00 ( 0.00%) 367.00 ( 4.92%)
Min total-odr1-16 361.00 ( 0.00%) 340.00 ( 5.82%)
Min total-odr1-32 352.00 ( 0.00%) 328.00 ( 6.82%)
Min total-odr1-64 345.00 ( 0.00%) 324.00 ( 6.09%)
Min total-odr1-128 347.00 ( 0.00%) 328.00 ( 5.48%)
Min total-odr1-256 347.00 ( 0.00%) 329.00 ( 5.19%)
Min total-odr1-512 354.00 ( 0.00%) 332.00 ( 6.21%)
Min total-odr1-1024 355.00 ( 0.00%) 337.00 ( 5.07%)
Min total-odr1-2048 358.00 ( 0.00%) 345.00 ( 3.63%)
Min total-odr1-4096 360.00 ( 0.00%) 346.00 ( 3.89%)
Min total-odr1-8192 360.00 ( 0.00%) 347.00 ( 3.61%)
A basic IO benchmark based on varying numbers of dd running in parallel
showed nothing interesting other than differences in what zones were
scanned due to the fair zone allocation policy being removed.
This series is not without its hazards. There are at least three areas
that I'm concerned with even though I could not reproduce any problems in
that area.
1. Reclaim/compaction is going to be affected because the amount of reclaim is
no longer targetted at a specific zone. Compaction works on a per-zone basis
so there is no guarantee that reclaiming a few THP's worth page pages will
have a positive impact on compaction success rates.
2. The Slab/LRU reclaim ratio is affected because the frequency the shrinkers
are called is now different. This may or may not be a problem but if it
is, it'll be because shrinkers are not called enough and some balancing
is required.
3. The anon/file reclaim ratio may be affected. Pages about to be dirtied are
distributed between zones and the fair zone allocation policy used to do
something very similar for anon. The distribution is now different but not
necessarily in any way that matters but it's still worth bearing in mind.
Documentation/cgroup-v1/memcg_test.txt | 4 +-
Documentation/cgroup-v1/memory.txt | 4 +-
arch/s390/appldata/appldata_mem.c | 2 +-
arch/tile/mm/pgtable.c | 18 +-
drivers/base/node.c | 73 +--
drivers/staging/android/lowmemorykiller.c | 12 +-
fs/fs-writeback.c | 4 +-
fs/fuse/file.c | 8 +-
fs/nfs/internal.h | 2 +-
fs/nfs/write.c | 2 +-
fs/proc/meminfo.c | 14 +-
include/linux/backing-dev.h | 2 +-
include/linux/memcontrol.h | 30 +-
include/linux/mm_inline.h | 2 +-
include/linux/mm_types.h | 2 +-
include/linux/mmzone.h | 157 +++---
include/linux/swap.h | 15 +-
include/linux/topology.h | 2 +-
include/linux/vm_event_item.h | 14 +-
include/linux/vmstat.h | 111 +++-
include/linux/writeback.h | 2 +-
include/trace/events/vmscan.h | 40 +-
include/trace/events/writeback.h | 10 +-
kernel/power/snapshot.c | 10 +-
kernel/sysctl.c | 4 +-
mm/backing-dev.c | 15 +-
mm/compaction.c | 39 +-
mm/filemap.c | 14 +-
mm/huge_memory.c | 33 +-
mm/internal.h | 11 +-
mm/memcontrol.c | 235 ++++-----
mm/memory-failure.c | 4 +-
mm/memory_hotplug.c | 7 +-
mm/mempolicy.c | 2 +-
mm/migrate.c | 35 +-
mm/mlock.c | 12 +-
mm/page-writeback.c | 124 +++--
mm/page_alloc.c | 271 +++++-----
mm/page_idle.c | 4 +-
mm/rmap.c | 15 +-
mm/shmem.c | 12 +-
mm/swap.c | 66 +--
mm/swap_state.c | 4 +-
mm/util.c | 4 +-
mm/vmscan.c | 829 +++++++++++++++---------------
mm/vmstat.c | 374 +++++++++++---
mm/workingset.c | 52 +-
47 files changed, 1489 insertions(+), 1217 deletions(-)
--
2.6.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-09 18:04 [PATCH 00/27] Move LRU page reclaim from zones to nodes v6 Mel Gorman @ 2016-06-09 18:04 ` Mel Gorman 2016-06-15 12:52 ` Vlastimil Babka 0 siblings, 1 reply; 11+ messages in thread From: Mel Gorman @ 2016-06-09 18:04 UTC (permalink / raw) To: Andrew Morton, Linux-MM Cc: Rik van Riel, Vlastimil Babka, Johannes Weiner, LKML, Mel Gorman This patch makes reclaim decisions on a per-node basis. A reclaimer knows what zone is required by the allocation request and skips pages from higher zones. In many cases this will be ok because it's a GFP_HIGHMEM request of some description. On 64-bit, ZONE_DMA32 requests will cause some problems but 32-bit devices on 64-bit platforms are increasingly rare. Historically it would have been a major problem on 32-bit with big Highmem:Lowmem ratios but such configurations are also now rare and even where they exist, they are not encouraged. If it really becomes a problem, it'll manifest as very low reclaim efficiencies. Signed-off-by: Mel Gorman <mgorman@techsingularity.net> --- mm/vmscan.c | 72 ++++++++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 47 insertions(+), 25 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index f87a5a0f8793..ab1b28e7e20a 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -84,6 +84,9 @@ struct scan_control { /* Scan (total_size >> priority) pages at once */ int priority; + /* The highest zone to isolate pages for reclaim from */ + enum zone_type reclaim_idx; + unsigned int may_writepage:1; /* Can mapped pages be reclaimed? */ @@ -1369,6 +1372,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, struct list_head *src = &lruvec->lists[lru]; unsigned long nr_taken = 0; unsigned long scan; + LIST_HEAD(pages_skipped); for (scan = 0; scan < nr_to_scan && nr_taken < nr_to_scan && !list_empty(src); scan++) { @@ -1379,6 +1383,11 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, VM_BUG_ON_PAGE(!PageLRU(page), page); + if (page_zonenum(page) > sc->reclaim_idx) { + list_move(&page->lru, &pages_skipped); + continue; + } + switch (__isolate_lru_page(page, mode)) { case 0: nr_taken += hpage_nr_pages(page); @@ -1395,6 +1404,15 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, } } + /* + * Splice any skipped pages to the start of the LRU list. Note that + * this disrupts the LRU order when reclaiming for lower zones but + * we cannot splice to the tail. If we did then the SWAP_CLUSTER_MAX + * scanning would soon rescan the same pages to skip and put the + * system at risk of premature OOM. + */ + if (!list_empty(&pages_skipped)) + list_splice(&pages_skipped, src); *nr_scanned = scan; trace_mm_vmscan_lru_isolate(sc->order, nr_to_scan, scan, nr_taken, mode, is_file_lru(lru)); @@ -1557,7 +1575,7 @@ static int current_may_throttle(void) } /* - * shrink_inactive_list() is a helper for shrink_zone(). It returns the number + * shrink_inactive_list() is a helper for shrink_node(). It returns the number * of reclaimed pages */ static noinline_for_stack unsigned long @@ -2371,12 +2389,13 @@ static inline bool should_continue_reclaim(struct zone *zone, } } -static bool shrink_zone(struct zone *zone, struct scan_control *sc, - bool is_classzone) +static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc, + enum zone_type classzone_idx) { struct reclaim_state *reclaim_state = current->reclaim_state; unsigned long nr_reclaimed, nr_scanned; bool reclaimable = false; + struct zone *zone = &pgdat->node_zones[classzone_idx]; do { struct mem_cgroup *root = sc->target_mem_cgroup; @@ -2408,7 +2427,7 @@ static bool shrink_zone(struct zone *zone, struct scan_control *sc, shrink_zone_memcg(zone, memcg, sc, &lru_pages); zone_lru_pages += lru_pages; - if (memcg && is_classzone) + if (!global_reclaim(sc) && sc->reclaim_idx == classzone_idx) shrink_slab(sc->gfp_mask, zone_to_nid(zone), memcg, sc->nr_scanned - scanned, lru_pages); @@ -2439,7 +2458,7 @@ static bool shrink_zone(struct zone *zone, struct scan_control *sc, * Shrink the slab caches in the same proportion that * the eligible LRU pages were scanned. */ - if (global_reclaim(sc) && is_classzone) + if (global_reclaim(sc) && sc->reclaim_idx == classzone_idx) shrink_slab(sc->gfp_mask, zone_to_nid(zone), NULL, sc->nr_scanned - nr_scanned, zone_lru_pages); @@ -2516,14 +2535,14 @@ static inline bool compaction_ready(struct zone *zone, int order, int classzone_ * If a zone is deemed to be full of pinned pages then just give it a light * scan then give up on it. */ -static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) +static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc, + enum zone_type classzone_idx) { struct zoneref *z; struct zone *zone; unsigned long nr_soft_reclaimed; unsigned long nr_soft_scanned; gfp_t orig_mask; - enum zone_type requested_highidx = gfp_zone(sc->gfp_mask); /* * If the number of buffer_heads in the machine exceeds the maximum @@ -2536,15 +2555,15 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) for_each_zone_zonelist_nodemask(zone, z, zonelist, gfp_zone(sc->gfp_mask), sc->nodemask) { - enum zone_type classzone_idx; - if (!populated_zone(zone)) continue; - classzone_idx = requested_highidx; while (!populated_zone(zone->zone_pgdat->node_zones + - classzone_idx)) + classzone_idx)) { + sc->reclaim_idx--; classzone_idx--; + continue; + } /* * Take care memory controller reclaiming has small influence @@ -2570,8 +2589,8 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) */ if (IS_ENABLED(CONFIG_COMPACTION) && sc->order > PAGE_ALLOC_COSTLY_ORDER && - zonelist_zone_idx(z) <= requested_highidx && - compaction_ready(zone, sc->order, requested_highidx)) { + zonelist_zone_idx(z) <= classzone_idx && + compaction_ready(zone, sc->order, classzone_idx)) { sc->compaction_ready = true; continue; } @@ -2591,7 +2610,7 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) /* need some check for avoid more shrink_zone() */ } - shrink_zone(zone, sc, zone_idx(zone) == classzone_idx); + shrink_node(zone->zone_pgdat, sc, classzone_idx); } /* @@ -2623,6 +2642,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, int initial_priority = sc->priority; unsigned long total_scanned = 0; unsigned long writeback_threshold; + enum zone_type classzone_idx = gfp_zone(sc->gfp_mask); retry: delayacct_freepages_start(); @@ -2633,7 +2653,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, vmpressure_prio(sc->gfp_mask, sc->target_mem_cgroup, sc->priority); sc->nr_scanned = 0; - shrink_zones(zonelist, sc); + shrink_zones(zonelist, sc, classzone_idx); total_scanned += sc->nr_scanned; if (sc->nr_reclaimed >= sc->nr_to_reclaim) @@ -3088,7 +3108,7 @@ static bool kswapd_shrink_zone(struct zone *zone, balance_gap, classzone_idx)) return true; - shrink_zone(zone, sc, zone_idx(zone) == classzone_idx); + shrink_node(zone->zone_pgdat, sc, classzone_idx); /* TODO: ANOMALY */ clear_bit(PGDAT_WRITEBACK, &pgdat->flags); @@ -3137,6 +3157,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) unsigned long nr_soft_scanned; struct scan_control sc = { .gfp_mask = GFP_KERNEL, + .reclaim_idx = MAX_NR_ZONES - 1, .order = order, .priority = DEF_PRIORITY, .may_writepage = !laptop_mode, @@ -3207,15 +3228,14 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) sc.may_writepage = 1; /* - * Now scan the zone in the dma->highmem direction, stopping - * at the last zone which needs scanning. - * - * We do this because the page allocator works in the opposite - * direction. This prevents the page allocator from allocating - * pages behind kswapd's direction of progress, which would - * cause too much scanning of the lower zones. + * Continue scanning in the highmem->dma direction stopping at + * the last zone which needs scanning. This may reclaim lowmem + * pages that are not necessary for zone balancing but it + * preserves LRU ordering. It is assumed that the bulk of + * allocation requests can use arbitrary zones with the + * possible exception of big highmem:lowmem configurations. */ - for (i = 0; i <= end_zone; i++) { + for (i = end_zone; i >= end_zone; i--) { struct zone *zone = pgdat->node_zones + i; if (!populated_zone(zone)) @@ -3226,6 +3246,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) continue; sc.nr_scanned = 0; + sc.reclaim_idx = i; nr_soft_scanned = 0; /* @@ -3674,6 +3695,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order) .may_writepage = !!(zone_reclaim_mode & RECLAIM_WRITE), .may_unmap = !!(zone_reclaim_mode & RECLAIM_UNMAP), .may_swap = 1, + .reclaim_idx = zone_idx(zone), }; cond_resched(); @@ -3693,7 +3715,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order) * priorities until we have enough memory freed. */ do { - shrink_zone(zone, &sc, true); + shrink_node(zone->zone_pgdat, &sc, zone_idx(zone)); } while (sc.nr_reclaimed < nr_pages && --sc.priority >= 0); } -- 2.6.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-06-09 18:04 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman @ 2016-06-15 12:52 ` Vlastimil Babka 0 siblings, 0 replies; 11+ messages in thread From: Vlastimil Babka @ 2016-06-15 12:52 UTC (permalink / raw) To: Mel Gorman, Andrew Morton, Linux-MM; +Cc: Rik van Riel, Johannes Weiner, LKML On 06/09/2016 08:04 PM, Mel Gorman wrote: > This patch makes reclaim decisions on a per-node basis. A reclaimer knows > what zone is required by the allocation request and skips pages from > higher zones. In many cases this will be ok because it's a GFP_HIGHMEM > request of some description. On 64-bit, ZONE_DMA32 requests will cause > some problems but 32-bit devices on 64-bit platforms are increasingly > rare. Historically it would have been a major problem on 32-bit with big > Highmem:Lowmem ratios but such configurations are also now rare and even > where they exist, they are not encouraged. If it really becomes a problem, > it'll manifest as very low reclaim efficiencies. > > Signed-off-by: Mel Gorman <mgorman@techsingularity.net> > --- > mm/vmscan.c | 72 ++++++++++++++++++++++++++++++++++++++++--------------------- > 1 file changed, 47 insertions(+), 25 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index f87a5a0f8793..ab1b28e7e20a 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -84,6 +84,9 @@ struct scan_control { > /* Scan (total_size >> priority) pages at once */ > int priority; > > + /* The highest zone to isolate pages for reclaim from */ > + enum zone_type reclaim_idx; > + > unsigned int may_writepage:1; > > /* Can mapped pages be reclaimed? */ > @@ -1369,6 +1372,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > struct list_head *src = &lruvec->lists[lru]; > unsigned long nr_taken = 0; > unsigned long scan; > + LIST_HEAD(pages_skipped); > > for (scan = 0; scan < nr_to_scan && nr_taken < nr_to_scan && > !list_empty(src); scan++) { > @@ -1379,6 +1383,11 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > > VM_BUG_ON_PAGE(!PageLRU(page), page); > > + if (page_zonenum(page) > sc->reclaim_idx) { > + list_move(&page->lru, &pages_skipped); > + continue; > + } > + > switch (__isolate_lru_page(page, mode)) { > case 0: > nr_taken += hpage_nr_pages(page); > @@ -1395,6 +1404,15 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > } > } > > + /* > + * Splice any skipped pages to the start of the LRU list. Note that > + * this disrupts the LRU order when reclaiming for lower zones but > + * we cannot splice to the tail. If we did then the SWAP_CLUSTER_MAX > + * scanning would soon rescan the same pages to skip and put the > + * system at risk of premature OOM. > + */ > + if (!list_empty(&pages_skipped)) > + list_splice(&pages_skipped, src); Hmm, that's unfortunate. But probably better than reclaiming the pages in the name of LRU order, even though it wouldn't help the allocation at hand. [...] > @@ -2516,14 +2535,14 @@ static inline bool compaction_ready(struct zone *zone, int order, int classzone_ > * If a zone is deemed to be full of pinned pages then just give it a light > * scan then give up on it. > */ > -static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > +static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc, > + enum zone_type classzone_idx) > { > struct zoneref *z; > struct zone *zone; > unsigned long nr_soft_reclaimed; > unsigned long nr_soft_scanned; > gfp_t orig_mask; > - enum zone_type requested_highidx = gfp_zone(sc->gfp_mask); > > /* > * If the number of buffer_heads in the machine exceeds the maximum > @@ -2536,15 +2555,15 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > > for_each_zone_zonelist_nodemask(zone, z, zonelist, > gfp_zone(sc->gfp_mask), sc->nodemask) { > - enum zone_type classzone_idx; > - > if (!populated_zone(zone)) > continue; > > - classzone_idx = requested_highidx; > while (!populated_zone(zone->zone_pgdat->node_zones + > - classzone_idx)) > + classzone_idx)) { > + sc->reclaim_idx--; > classzone_idx--; > + continue; Isn't this wrong to do this across whole zonelist which will contain multiple nodes? Example: a small node 0 without Normal zone will get us sc->reclaim_idx == classzone_idx == dma32. Node 1 won't have dma/dma32 zones so we won't see classzone_idx populated, and the while loop will lead to underflow? And sc->reclaim_idx seems to be unitialized when called via try_to_free_pages() -> do_try_to_free_pages() -> shrink_zones() ? Which means it's zero and we underflow immediately? > @@ -3207,15 +3228,14 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) > sc.may_writepage = 1; > > /* > - * Now scan the zone in the dma->highmem direction, stopping > - * at the last zone which needs scanning. > - * > - * We do this because the page allocator works in the opposite > - * direction. This prevents the page allocator from allocating > - * pages behind kswapd's direction of progress, which would > - * cause too much scanning of the lower zones. > + * Continue scanning in the highmem->dma direction stopping at > + * the last zone which needs scanning. This may reclaim lowmem > + * pages that are not necessary for zone balancing but it > + * preserves LRU ordering. It is assumed that the bulk of > + * allocation requests can use arbitrary zones with the > + * possible exception of big highmem:lowmem configurations. > */ > - for (i = 0; i <= end_zone; i++) { > + for (i = end_zone; i >= end_zone; i--) { i >= 0 ? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 00/27] Move LRU page reclaim from zones to nodes v5
@ 2016-04-15 9:13 Mel Gorman
2016-04-15 9:13 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman
0 siblings, 1 reply; 11+ messages in thread
From: Mel Gorman @ 2016-04-15 9:13 UTC (permalink / raw)
To: Andrew Morton, Linux-MM
Cc: Rik van Riel, Vlastimil Babka, Johannes Weiner,
Jesper Dangaard Brouer, LKML, Mel Gorman
Changelog since v4
o Rebase on top of v3 of page allocator optimisation series
Changelog since v3
o Rebase on top of the page allocator optimisation series
o Remove RFC tag
This is the latest version of a series that moves LRUs from the zones to
the node that is based upon 4.6-rc3 plus the page allocator optimisation
series. Conceptually, this is simple but there are a lot of details. Some
of the broad motivations for this are;
1. The residency of a page partially depends on what zone the page was
allocated from. This is partially combatted by the fair zone allocation
policy but that is a partial solution that introduces overhead in the
page allocator paths.
2. Currently, reclaim on node 0 behaves slightly different to node 1. For
example, direct reclaim scans in zonelist order and reclaims even if
the zone is over the high watermark regardless of the age of pages
in that LRU. Kswapd on the other hand starts reclaim on the highest
unbalanced zone. A difference in distribution of file/anon pages due
to when they were allocated results can result in a difference in
again. While the fair zone allocation policy mitigates some of the
problems here, the page reclaim results on a multi-zone node will
always be different to a single-zone node.
it was scheduled on as a result.
3. kswapd and the page allocator scan zones in the opposite order to
avoid interfering with each other but it's sensitive to timing. This
mitigates the page allocator using pages that were allocated very recently
in the ideal case but it's sensitive to timing. When kswapd is allocating
from lower zones then it's great but during the rebalancing of the highest
zone, the page allocator and kswapd interfere with each other. It's worse
if the highest zone is small and difficult to balance.
4. slab shrinkers are node-based which makes it harder to identify the exact
relationship between slab reclaim and LRU reclaim.
The reason we have zone-based reclaim is that we used to have
large highmem zones in common configurations and it was necessary
to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
less of a concern as machines with lots of memory will (or should) use
64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
rare. Machines that do use highmem should have relatively low highmem:lowmem
ratios than we worried about in the past.
Conceptually, moving to node LRUs should be easier to understand. The
page allocator plays fewer tricks to game reclaim and reclaim behaves
similarly on all nodes.
It was tested on a UMA (16 cores single socket) and a NUMA machine (48
cores, 2 sockets). In most cases, only the UMA results are presented as
the NUMA machine takes an excessive amount of time to complete tests.
There may be an obvious difference in the number of
allocations from each zone as the fair zone allocation policy is removed
towards the end of the series. In cases where the working set exceeds memory,
the differences will be small but on small workloads it'll be very obvious.
For example, these are the allocation stats on a workload that is doing small
amounts of dd.
4.6.0-rc1 4.6.0-rc1
vanilla nodelru-v3
DMA allocs 0 0
DMA32 allocs 1961196 0
Normal allocs 3355799 5247180
Movable allocs 0 0
The key reason why this is not a problem is that kswapd will sleep if any
applicable zone for a classzone is free. If it tried to balance all zones
then there would be excessive reclaim.
bonnie
------
This was configured to do an IO test with a working set 2*RAM using the
ext4 filesystem. For both machines, there was no significant performance
difference between them but this is the result for the UMA machine
bonnie
4.6.0-rc1 4.6.0-rc1
vanilla nodelru-v3r10
Hmean SeqOut Char 53306.32 ( 0.00%) 79027.86 ( 48.25%)
Hmean SeqOut Block 87796.15 ( 0.00%) 87881.69 ( 0.10%)
Hmean SeqOut Rewrite 35996.31 ( 0.00%) 36355.59 ( 1.00%)
Hmean SeqIn Char 38789.17 ( 0.00%) 76356.20 ( 96.85%)
Hmean SeqIn Block 105315.39 ( 0.00%) 105514.07 ( 0.19%)
Hmean Random seeks 329.80 ( 0.00%) 334.36 ( 1.38%)
Hmean SeqCreate ops 4.62 ( 0.00%) 4.62 ( 0.00%)
Hmean SeqCreate read 4.62 ( 0.00%) 4.62 ( 0.00%)
Hmean SeqCreate del 599.29 ( 0.00%) 1580.23 (163.68%)
Hmean RandCreate ops 5.00 ( 0.00%) 5.00 ( 0.00%)
Hmean RandCreate read 5.00 ( 0.00%) 4.62 ( -7.69%)
Hmean RandCreate del 629.51 ( 0.00%) 1634.55 (159.66%)
4.6.0-rc1 4.6.0-rc1
vanillanodelru-v3r10
User 2049.02 1078.82
System 294.25 181.00
Elapsed 6960.58 6021.58
Note that the massive gains shown here are possible an anomaly. It has been noted
that in some cases, bonnie gets an artifical boost due to dumb reclaim luck. There
is no guarantee this result would be reproducible on the same machine let alone
any other machine. That said, the VM stats are interesting;
However, the overall VM stats are interesting
4.5.0-rc3 4.5.0-rc3
mmotm-20160209 nodelru-v2
Swap Ins 14 0
Swap Outs 873 0
DMA allocs 0 0
DMA32 allocs 38259888 36320496
Normal allocs 64762073 66488556
Movable allocs 0 0
Allocation stalls 3584 0
Direct pages scanned 736769 0
Kswapd pages scanned 77818637 78836064
Kswapd pages reclaimed 77782378 78812260
Direct pages reclaimed 736548 0
Kswapd efficiency 99% 99%
Kswapd velocity 11179.907 13092.256
Direct efficiency 99% 100%
Direct velocity 105.849 0.000
The series does not swap the workload and it never stalls on direct reclaim. There
is a slight increase in kswapd scans but it's offset by the elimination of direct
scans and the overall scanning velocity is not noticably higher. While it's not
reported here, the overall IO stats and CPU usage over time are very similar. kswapd
CPU usage is slightly elevated but (0.5% usage to roughly 1.2% usage over time) but
that is acceptable given the lack of direct reclaim.
tiobench
--------
tiobench is a flawed benchmark but it's very important in this case. tiobench
benefited from a bug prior to the fair zone allocation policy that allowed
old pages to be artificially preserved. The visible impact was that performance
exceeded the physical capabilities of the disk. With this patch applied the results are
tiobench Throughput
tiobench Throughput
4.6.0-rc1 4.6.0-rc1
vanilla nodelru-v3
Hmean PotentialReadSpeed 85.84 ( 0.00%) 86.20 ( 0.42%)
Hmean SeqRead-MB/sec-1 84.48 ( 0.00%) 84.60 ( 0.14%)
Hmean SeqRead-MB/sec-2 75.69 ( 0.00%) 75.44 ( -0.34%)
Hmean SeqRead-MB/sec-4 77.35 ( 0.00%) 77.62 ( 0.35%)
Hmean SeqRead-MB/sec-8 68.29 ( 0.00%) 68.58 ( 0.43%)
Hmean SeqRead-MB/sec-16 62.82 ( 0.00%) 62.72 ( -0.15%)
Hmean RandRead-MB/sec-1 0.93 ( 0.00%) 0.88 ( -4.69%)
Hmean RandRead-MB/sec-2 1.11 ( 0.00%) 1.08 ( -3.20%)
Hmean RandRead-MB/sec-4 1.52 ( 0.00%) 1.48 ( -2.86%)
Hmean RandRead-MB/sec-8 1.70 ( 0.00%) 1.70 ( -0.26%)
Hmean RandRead-MB/sec-16 1.96 ( 0.00%) 1.91 ( -2.49%)
Hmean SeqWrite-MB/sec-1 83.01 ( 0.00%) 83.07 ( 0.07%)
Hmean SeqWrite-MB/sec-2 77.80 ( 0.00%) 78.20 ( 0.52%)
Hmean SeqWrite-MB/sec-4 81.68 ( 0.00%) 81.72 ( 0.05%)
Hmean SeqWrite-MB/sec-8 78.17 ( 0.00%) 78.41 ( 0.31%)
Hmean SeqWrite-MB/sec-16 80.08 ( 0.00%) 80.08 ( 0.01%)
Hmean RandWrite-MB/sec-1 1.17 ( 0.00%) 1.17 ( -0.03%)
Hmean RandWrite-MB/sec-2 1.02 ( 0.00%) 1.06 ( 4.21%)
Hmean RandWrite-MB/sec-4 1.02 ( 0.00%) 1.04 ( 2.32%)
Hmean RandWrite-MB/sec-8 0.95 ( 0.00%) 0.97 ( 1.75%)
Hmean RandWrite-MB/sec-16 0.95 ( 0.00%) 0.96 ( 0.97%)
Note that the performance is almost identical allowing us to conclude that
the correct reclaim behaviour granted by the fair zone allocation policy
is preserved.
stutter
-------
stutter simulates a simple workload. One part uses a lot of anonymous
memory, a second measures mmap latency and a third copies a large file.
The primary metric is checking for mmap latency.
stutter
4.6.0-rc1 4.6.0-rc1
vanilla nodelru-v3
Min mmap 13.4442 ( 0.00%) 13.6705 ( -1.68%)
1st-qrtle mmap 38.0442 ( 0.00%) 37.7842 ( 0.68%)
2nd-qrtle mmap 78.5109 ( 0.00%) 40.3648 ( 48.59%)
3rd-qrtle mmap 86.7806 ( 0.00%) 46.2499 ( 46.70%)
Max-90% mmap 89.7028 ( 0.00%) 86.5790 ( 3.48%)
Max-93% mmap 90.6776 ( 0.00%) 89.5367 ( 1.26%)
Max-95% mmap 91.1678 ( 0.00%) 90.3138 ( 0.94%)
Max-99% mmap 92.0036 ( 0.00%) 93.2003 ( -1.30%)
Max mmap 167.0073 ( 0.00%) 94.5935 ( 43.36%)
Mean mmap 68.7672 ( 0.00%) 48.9853 ( 28.77%)
Best99%Mean mmap 68.5246 ( 0.00%) 48.5354 ( 29.17%)
Best95%Mean mmap 67.5540 ( 0.00%) 46.7102 ( 30.86%)
Best90%Mean mmap 66.2798 ( 0.00%) 44.3547 ( 33.08%)
Best50%Mean mmap 50.7730 ( 0.00%) 37.1298 ( 26.87%)
Best10%Mean mmap 35.8311 ( 0.00%) 33.6910 ( 5.97%)
Best5%Mean mmap 34.0159 ( 0.00%) 31.4259 ( 7.61%)
Best1%Mean mmap 22.1306 ( 0.00%) 24.8851 (-12.45%)
4.6.0-rc1 4.6.0-rc1
vanillanodelru-v3r10
User 1.51 0.97
System 138.03 122.58
Elapsed 2420.90 2394.80
The VM stats in this case were not that intresting and are very roughly comparable.
Page allocator intensive workloads showed few differences as the cost
of the fair zone allocation policy does not dominate from a userspace
perspective but a microbench of just the allocator shows a difference
4.6.0-rc1 4.6.0-rc1
vanilla nodelru-v3
Min total-odr0-1 725.00 ( 0.00%) 697.00 ( 3.86%)
Min total-odr0-2 559.00 ( 0.00%) 527.00 ( 5.72%)
Min total-odr0-4 459.00 ( 0.00%) 436.00 ( 5.01%)
Min total-odr0-8 403.00 ( 0.00%) 391.00 ( 2.98%)
Min total-odr0-16 329.00 ( 0.00%) 366.00 (-11.25%)
Min total-odr0-32 365.00 ( 0.00%) 355.00 ( 2.74%)
Min total-odr0-64 297.00 ( 0.00%) 348.00 (-17.17%)
Min total-odr0-128 752.00 ( 0.00%) 344.00 ( 54.26%)
Min total-odr0-256 385.00 ( 0.00%) 379.00 ( 1.56%)
Min total-odr0-512 899.00 ( 0.00%) 414.00 ( 53.95%)
Min total-odr0-1024 763.00 ( 0.00%) 530.00 ( 30.54%)
Min total-odr0-2048 982.00 ( 0.00%) 469.00 ( 52.24%)
Min total-odr0-4096 928.00 ( 0.00%) 526.00 ( 43.32%)
Min total-odr0-8192 1007.00 ( 0.00%) 768.00 ( 23.73%)
Min total-odr0-16384 375.00 ( 0.00%) 366.00 ( 2.40%)
This series is not without its hazards. There are at least three areas
that I'm concerned with even though I could not reproduce any problems in
that area.
1. Reclaim/compaction is going to be affected because the amount of reclaim is
no longer targetted at a specific zone. Compaction works on a per-zone basis
so there is no guarantee that reclaiming a few THP's worth page pages will
have a positive impact on compaction success rates.
2. The Slab/LRU reclaim ratio is affected because the frequency the shrinkers
are called is now different. This may or may not be a problem but if it
is, it'll be because shrinkers are not called enough and some balancing
is required.
3. The anon/file reclaim ratio may be affected. Pages about to be dirtied are
distributed between zones and the fair zone allocation policy used to do
something very similar for anon. The distribution is now different but not
necessarily in any way that matters but it's still worth bearing in mind.
Documentation/cgroup-v1/memcg_test.txt | 4 +-
Documentation/cgroup-v1/memory.txt | 4 +-
arch/s390/appldata/appldata_mem.c | 2 +-
arch/tile/mm/pgtable.c | 18 +-
drivers/base/node.c | 73 +--
drivers/staging/android/lowmemorykiller.c | 12 +-
fs/fs-writeback.c | 4 +-
fs/fuse/file.c | 8 +-
fs/nfs/internal.h | 2 +-
fs/nfs/write.c | 2 +-
fs/proc/meminfo.c | 14 +-
include/linux/backing-dev.h | 2 +-
include/linux/memcontrol.h | 30 +-
include/linux/mm_inline.h | 4 +-
include/linux/mm_types.h | 2 +-
include/linux/mmzone.h | 156 +++---
include/linux/swap.h | 13 +-
include/linux/topology.h | 2 +-
include/linux/vm_event_item.h | 14 +-
include/linux/vmstat.h | 111 +++-
include/linux/writeback.h | 2 +-
include/trace/events/vmscan.h | 40 +-
include/trace/events/writeback.h | 10 +-
kernel/power/snapshot.c | 10 +-
kernel/sysctl.c | 4 +-
mm/backing-dev.c | 14 +-
mm/compaction.c | 24 +-
mm/filemap.c | 14 +-
mm/huge_memory.c | 14 +-
mm/internal.h | 11 +-
mm/memcontrol.c | 235 ++++-----
mm/memory-failure.c | 4 +-
mm/memory_hotplug.c | 7 +-
mm/mempolicy.c | 2 +-
mm/migrate.c | 35 +-
mm/mlock.c | 12 +-
mm/page-writeback.c | 119 ++---
mm/page_alloc.c | 289 +++++-----
mm/page_idle.c | 4 +-
mm/rmap.c | 15 +-
mm/shmem.c | 12 +-
mm/swap.c | 66 +--
mm/swap_state.c | 4 +-
mm/util.c | 4 +-
mm/vmscan.c | 847 ++++++++++++++----------------
mm/vmstat.c | 369 ++++++++++---
mm/workingset.c | 53 +-
47 files changed, 1476 insertions(+), 1221 deletions(-)
--
2.6.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis 2016-04-15 9:13 [PATCH 00/27] Move LRU page reclaim from zones to nodes v5 Mel Gorman @ 2016-04-15 9:13 ` Mel Gorman 0 siblings, 0 replies; 11+ messages in thread From: Mel Gorman @ 2016-04-15 9:13 UTC (permalink / raw) To: Andrew Morton, Linux-MM Cc: Rik van Riel, Vlastimil Babka, Johannes Weiner, Jesper Dangaard Brouer, LKML, Mel Gorman This patch makes reclaim decisions on a per-node basis. A reclaimer knows what zone is required by the allocation request and skips pages from higher zones. In many cases this will be ok because it's a GFP_HIGHMEM request of some description. On 64-bit, ZONE_DMA32 requests will cause some problems but 32-bit devices on 64-bit platforms are increasingly rare. Historically it would have been a major problem on 32-bit with big Highmem:Lowmem ratios but such configurations are also now rare and even where they exist, they are not encouraged. If it really becomes a problem, it'll manifest as very low reclaim efficiencies. Signed-off-by: Mel Gorman <mgorman@techsingularity.net> --- mm/vmscan.c | 77 ++++++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 48 insertions(+), 29 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 75acb89c9df5..0f8dc3488f9d 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -84,6 +84,9 @@ struct scan_control { /* Scan (total_size >> priority) pages at once */ int priority; + /* The highest zone to isolate pages for reclaim from */ + enum zone_type reclaim_idx; + unsigned int may_writepage:1; /* Can mapped pages be reclaimed? */ @@ -1369,6 +1372,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, struct list_head *src = &lruvec->lists[lru]; unsigned long nr_taken = 0; unsigned long scan; + LIST_HEAD(pages_skipped); for (scan = 0; scan < nr_to_scan && nr_taken < nr_to_scan && !list_empty(src); scan++) { @@ -1380,6 +1384,11 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, VM_BUG_ON_PAGE(!PageLRU(page), page); + if (page_zonenum(page) > sc->reclaim_idx) { + list_move(&page->lru, &pages_skipped); + continue; + } + switch (__isolate_lru_page(page, mode)) { case 0: nr_pages = hpage_nr_pages(page); @@ -1398,6 +1407,15 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, } } + /* + * Splice any skipped pages to the start of the LRU list. Note that + * this disrupts the LRU order when reclaiming for lower zones but + * we cannot splice to the tail. If we did then the SWAP_CLUSTER_MAX + * scanning would soon rescan the same pages to skip and put the + * system at risk of premature OOM. + */ + if (!list_empty(&pages_skipped)) + list_splice(&pages_skipped, src); *nr_scanned = scan; trace_mm_vmscan_lru_isolate(sc->order, nr_to_scan, scan, nr_taken, mode, is_file_lru(lru)); @@ -1560,7 +1578,7 @@ static int current_may_throttle(void) } /* - * shrink_inactive_list() is a helper for shrink_zone(). It returns the number + * shrink_inactive_list() is a helper for shrink_node(). It returns the number * of reclaimed pages */ static noinline_for_stack unsigned long @@ -2394,12 +2412,13 @@ static inline bool should_continue_reclaim(struct zone *zone, } } -static bool shrink_zone(struct zone *zone, struct scan_control *sc, - bool is_classzone) +static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc, + enum zone_type classzone_idx) { struct reclaim_state *reclaim_state = current->reclaim_state; unsigned long nr_reclaimed, nr_scanned; bool reclaimable = false; + struct zone *zone = &pgdat->node_zones[classzone_idx]; do { struct mem_cgroup *root = sc->target_mem_cgroup; @@ -2431,7 +2450,7 @@ static bool shrink_zone(struct zone *zone, struct scan_control *sc, shrink_zone_memcg(zone, memcg, sc, &lru_pages); zone_lru_pages += lru_pages; - if (memcg && is_classzone) + if (!global_reclaim(sc) && sc->reclaim_idx == classzone_idx) shrink_slab(sc->gfp_mask, zone_to_nid(zone), memcg, sc->nr_scanned - scanned, lru_pages); @@ -2462,7 +2481,7 @@ static bool shrink_zone(struct zone *zone, struct scan_control *sc, * Shrink the slab caches in the same proportion that * the eligible LRU pages were scanned. */ - if (global_reclaim(sc) && is_classzone) + if (global_reclaim(sc) && sc->reclaim_idx == classzone_idx) shrink_slab(sc->gfp_mask, zone_to_nid(zone), NULL, sc->nr_scanned - nr_scanned, zone_lru_pages); @@ -2541,14 +2560,14 @@ static inline bool compaction_ready(struct zone *zone, int order) * * Returns true if a zone was reclaimable. */ -static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc) +static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc, + enum zone_type classzone_idx) { struct zoneref *z; struct zone *zone; unsigned long nr_soft_reclaimed; unsigned long nr_soft_scanned; gfp_t orig_mask; - enum zone_type requested_highidx = gfp_zone(sc->gfp_mask); bool reclaimable = false; /* @@ -2561,16 +2580,12 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc) sc->gfp_mask |= __GFP_HIGHMEM; for_each_zone_zonelist_nodemask(zone, z, zonelist, - requested_highidx, sc->nodemask) { - enum zone_type classzone_idx; - - if (!populated_zone(zone)) - continue; - - classzone_idx = requested_highidx; - while (!populated_zone(zone->zone_pgdat->node_zones + - classzone_idx)) + classzone_idx, sc->nodemask) { + if (!populated_zone(zone)) { + sc->reclaim_idx--; classzone_idx--; + continue; + } /* * Take care memory controller reclaiming has small influence @@ -2596,7 +2611,7 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc) */ if (IS_ENABLED(CONFIG_COMPACTION) && sc->order > PAGE_ALLOC_COSTLY_ORDER && - zonelist_zone_idx(z) <= requested_highidx && + zonelist_zone_idx(z) <= classzone_idx && compaction_ready(zone, sc->order)) { sc->compaction_ready = true; continue; @@ -2619,7 +2634,7 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc) /* need some check for avoid more shrink_zone() */ } - if (shrink_zone(zone, sc, zone_idx(zone) == classzone_idx)) + if (shrink_node(zone->zone_pgdat, sc, classzone_idx)) reclaimable = true; if (global_reclaim(sc) && @@ -2659,6 +2674,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, unsigned long total_scanned = 0; unsigned long writeback_threshold; bool zones_reclaimable; + enum zone_type classzone_idx = gfp_zone(sc->gfp_mask); retry: delayacct_freepages_start(); @@ -2669,7 +2685,8 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, vmpressure_prio(sc->gfp_mask, sc->target_mem_cgroup, sc->priority); sc->nr_scanned = 0; - zones_reclaimable = shrink_zones(zonelist, sc); + sc->reclaim_idx = classzone_idx; + zones_reclaimable = shrink_zones(zonelist, sc, classzone_idx); total_scanned += sc->nr_scanned; if (sc->nr_reclaimed >= sc->nr_to_reclaim) @@ -3128,7 +3145,7 @@ static bool kswapd_shrink_zone(struct zone *zone, balance_gap, classzone_idx)) return true; - shrink_zone(zone, sc, zone_idx(zone) == classzone_idx); + shrink_node(zone->zone_pgdat, sc, classzone_idx); /* TODO: ANOMALY */ clear_bit(PGDAT_WRITEBACK, &pgdat->flags); @@ -3177,6 +3194,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) unsigned long nr_soft_scanned; struct scan_control sc = { .gfp_mask = GFP_KERNEL, + .reclaim_idx = MAX_NR_ZONES - 1, .order = order, .priority = DEF_PRIORITY, .may_writepage = !laptop_mode, @@ -3247,15 +3265,14 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) sc.may_writepage = 1; /* - * Now scan the zone in the dma->highmem direction, stopping - * at the last zone which needs scanning. - * - * We do this because the page allocator works in the opposite - * direction. This prevents the page allocator from allocating - * pages behind kswapd's direction of progress, which would - * cause too much scanning of the lower zones. + * Continue scanning in the highmem->dma direction stopping at + * the last zone which needs scanning. This may reclaim lowmem + * pages that are not necessary for zone balancing but it + * preserves LRU ordering. It is assumed that the bulk of + * allocation requests can use arbitrary zones with the + * possible exception of big highmem:lowmem configurations. */ - for (i = 0; i <= end_zone; i++) { + for (i = end_zone; i >= end_zone; i--) { struct zone *zone = pgdat->node_zones + i; if (!populated_zone(zone)) @@ -3266,6 +3283,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx) continue; sc.nr_scanned = 0; + sc.reclaim_idx = i; nr_soft_scanned = 0; /* @@ -3714,6 +3732,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order) .may_writepage = !!(zone_reclaim_mode & RECLAIM_WRITE), .may_unmap = !!(zone_reclaim_mode & RECLAIM_UNMAP), .may_swap = 1, + .reclaim_idx = zone_idx(zone), }; cond_resched(); @@ -3733,7 +3752,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order) * priorities until we have enough memory freed. */ do { - shrink_zone(zone, &sc, true); + shrink_node(zone->zone_pgdat, &sc, zone_idx(zone)); } while (sc.nr_reclaimed < nr_pages && --sc.priority >= 0); } -- 2.6.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-06-23 11:13 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <02ed01d1c47a$49fbfbc0$ddf3f340$@alibaba-inc.com>
2016-06-12 7:33 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Hillf Danton
2016-06-14 14:47 ` Mel Gorman
2016-06-21 14:15 [PATCH 00/27] Move LRU page reclaim from zones to nodes v7 Mel Gorman
2016-06-21 14:15 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman
2016-06-22 14:04 ` Vlastimil Babka
2016-06-22 16:00 ` Vlastimil Babka
2016-06-23 11:07 ` Mel Gorman
2016-06-23 11:13 ` Michal Hocko
2016-06-23 10:58 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2016-06-09 18:04 [PATCH 00/27] Move LRU page reclaim from zones to nodes v6 Mel Gorman
2016-06-09 18:04 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman
2016-06-15 12:52 ` Vlastimil Babka
2016-04-15 9:13 [PATCH 00/27] Move LRU page reclaim from zones to nodes v5 Mel Gorman
2016-04-15 9:13 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox