* [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
@ 2016-01-29 19:23 ` ChengYi He
0 siblings, 0 replies; 16+ messages in thread
From: ChengYi He @ 2016-01-29 19:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Michal Hocko, Vlastimil Babka, David Rientjes,
Joonsoo Kim, Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel, chengyihetaipei
The patchset tries to avoid external fragmentation related to migration
fallback. The symptom of this external fragmentation is that there are
lots of allocation failures of order-2 and order-3 pages and many
threads enter allocation slowpath to compact and direct reclaim pages.
This will degrade system performance and make it less responsive to
users. This symptom could be observed in devices which have only one
memory zone, such as some arm64 android devices. Below are two examples
in which processes fail to allocate order-2 and order-3 pages and enter
direct reclaim.
1) In arm64, THREAD_SIZE_ORDER is 2. The thread enters direct reclaim
while allocating an order-2 page as kernel stack.
[<ffffffc0002077dc>] dump_backtrace+0x0/0x134
[<ffffffc000207920>] show_stack+0x10/0x1c
[<ffffffc000cedc64>] dump_stack+0x1c/0x28
[<ffffffc0002cb6bc>] try_to_free_pages+0x5d8/0x704
[<ffffffc0002c219c>] __alloc_pages_nodemask+0x544/0x834
[<ffffffc00021a1e4>] copy_process.part.58+0xf4/0xdfc
[<ffffffc00021b000>] do_fork+0xe0/0x358
[<ffffffc00021b310>] SyS_clone+0x10/0x1c
2) The thread enters direct reclaim while allocating an order-3 page.
[<ffffffc0002077dc>] dump_backtrace+0x0/0x134
[<ffffffc000207920>] show_stack+0x10/0x1c
[<ffffffc000cedc64>] dump_stack+0x1c/0x28
[<ffffffc0002cb6bc>] try_to_free_pages+0x5d8/0x704
[<ffffffc0002c219c>] __alloc_pages_nodemask+0x544/0x834
[<ffffffc0002f0c68>] new_slab+0x80/0x23c
[<ffffffc0002f2780>] __slab_alloc.isra.50.constprop.55+0x26c/0x300
[<ffffffc0002f2abc>] kmem_cache_alloc+0x94/0x1d4
[<ffffffc0003e3a1c>] fuse_alloc_inode+0x20/0xb8
[<ffffffc00030f468>] alloc_inode+0x1c/0x90
[<ffffffc000310134>] iget5_locked+0xa0/0x1c0
[<ffffffc0003e3d00>] fuse_iget+0x60/0x1bc
[<ffffffc0003de13c>] fuse_lookup_name+0x140/0x194
[<ffffffc0003de1c4>] fuse_lookup+0x34/0x110
[<ffffffc00030236c>] lookup_real+0x30/0x54
[<ffffffc000302efc>] __lookup_hash+0x30/0x48
[<ffffffc00030377c>] lookup_slow+0x44/0xbc
[<ffffffc000304dd8>] path_lookupat+0x104/0x710
[<ffffffc00030540c>] filename_lookup.isra.32+0x28/0x74
[<ffffffc0003072cc>] user_path_at_empty+0x58/0x88
[<ffffffc000307308>] user_path_at+0xc/0x18
[<ffffffc0002f8764>] SyS_faccessat+0xc0/0x1bc
Below is the root cause of this external fragmentation which could be
observed in devices which have only one memory zone, such as some arm64
android devices:
1) In arm64, the first 4GB physical address space is of DMA zone. If the
size of physical memory is less than 4GB and the whole memory is in the
first 4GB address space, then the system will have only one DMA zone.
2) By default, all pageblocks are Movable.
3) Allocators such as slab, ion, graphics preferably allocate pages of
Unmvoable migration type. It might fallback to allocate Movable pages
and changes Movable pageblocks into Unmovable ones.
4) Movable pagesblocks will become less and less due to above reason.
However, in android system, AnonPages request is always high. The
Movable pages will be easily exhausted.
5) While Movable pages are exhausted, the Movable allocations will
frequently fallback to allocate the largest feasiable pages of the other
migration types. The order-2 and order-3 Unmovable pages will be split
into smaller ones easily.
This symptom doesn't appear in arm32 android which usually has two
memory zones including Highmem and Normal. The slab, ion, and graphics
allocators allocate pages with flag GFP_KERNEL. Only Movable pageblocks
in Normal zone become less, and the Movable pages in Highmem zone are
still a lot. Thus, the Movable pages will not be easily exhausted, and
there will not be frequent fallbacks.
Since the root cause is that fallbacks might frequently split order-2
and order-3 pages of the other migration types. This patch tweaks
fallback mechanism to avoid splitting order-2 and order-3 pages. while
fallbacks happen, if the largest feasible pages are less than or queal to
COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
reason why fallbacks prefer the largest feasiable pages is to increase
fallback efficiency since fallbacks are likely to happen again. By
stealing the largest feasible pages, it could reduce the oppourtunities
of antoher fallback. Besides, it could make consecutive allocations more
approximate to each other and make system less fragment. However, if the
largest feasible pages are less than or equal to order-3, fallbacks might
split it and make the upcoming order-3 page allocations fail.
My test is against arm64 android devices with kernel 3.10.49. I set the
same account and install the same applications in both deivces and use
them synchronously.
Test result:
1) Test without this patch:
Most free pages are order-0 Unmovable ones. allocstall and compact_stall
in /proc/vmstat are relatively high. And most occurances of allocstall
are due to order-2 and order-3 allocations.
2) Test with this patch:
There are more order-2 and order-3 free pages. allocstall and
compact_stall in /proc/vmstat are relatively low. And most occurances of
allocstall are due to order-0 allocations.
Log:
1) Test without this patch:
------ TIME (date) ------
Fri Jul 3 16:52:55 CST 2015
------ UPTIME (uptime) ------
up time: 2 days, 12:06:52, idle time: 8 days, 14:48:55, sleep time: 16:43:56
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 2792568 kB
MemFree: 194524 kB
Buffers: 3788 kB
Cached: 380872 kB
------ PAGETYPEINFO (/proc/pagetypeinfo) ------
Free pages count per migrate type at order 0 1 2 3 4
Node 0, zone DMA, type Unmovable 43852 701 0 0 0
Node 0, zone DMA, type Reclaimable 3357 0 0 0 0
Node 0, zone DMA, type Movable 0 5 0 0 0
Node 0, zone DMA, type Reserve 0 1 5 0 0
Node 0, zone DMA, type CMA 2 0 0 0 0
Node 0, zone DMA, type Isolate 0 0 0 0 0
Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
Node 0, zone DMA 362 80 170 2 113 0
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
pgsteal_kswapd_dma 31755040
pgsteal_direct_dma 34597394
pgscan_kswapd_dma 36427664
pgscan_direct_dma 39490711
kswapd_low_wmark_hit_quickly 201929
kswapd_high_wmark_hit_quickly 4858
allocstall 664269
allocstall_order_0 9738
allocstall_order_1 1787
allocstall_order_2 637608
allocstall_order_3 15136
pgmigrate_success 2941956
pgmigrate_fail 1033
compact_migrate_scanned 142985157
compact_free_scanned 4734040109
compact_isolated 7720362
compact_stall 65978
compact_fail 46084
compact_success 11717
2) Test with this patch:
------ TIME (date) ------
Fri Jul 3 16:52:31 CST 2015
------ UPTIME (uptime) ------
up time: 2 days, 12:06:30
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 2792568 kB
MemFree: 47612 kB
Buffers: 3732 kB
Cached: 387048 kB
------ PAGETYPEINFO (/proc/pagetypeinfo) ------
Free pages count per migrate type at order 0 1 2 3 4
Node 0, zone DMA, type Unmovable 272 243 126 1 0
Node 0, zone DMA, type Reclaimable 0 361 168 46 0
Node 0, zone DMA, type Movable 4103 1782 130 3 0
Node 0, zone DMA, type Reserve 0 0 0 0 0
Node 0, zone DMA, type CMA 563 2 0 0 0
Node 0, zone DMA, type Isolate 0 0 0 0 0
Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
Node 0, zone DMA 183 12 417 2 113 0
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
pgsteal_kswapd_dma 50710868
pgsteal_direct_dma 1756780
pgscan_kswapd_dma 58281837
pgscan_direct_dma 2022049
kswapd_low_wmark_hit_quickly 37599
kswapd_high_wmark_hit_quickly 13564
allocstall 27510
allocstall_order_0 26101
allocstall_order_1 23
allocstall_order_2 1224
allocstall_order_3 162
pgmigrate_success 63751
pgmigrate_fail 7
compact_migrate_scanned 278170
compact_free_scanned 6155410
compact_isolated 140762
compact_stall 749
compact_fail 54
compact_success 22
unevictable_pgs_culled 794
Below is the status of another device with this patch.
/proc/pagetypeinfo shows that even if there are no Movable pages, there
are lots of order-2 and order-3 Unmovable pages. For this case, if the
patch is not applied, then order-2 and order-3 Unmovable pages will be
split easily. It's likely that system perforamnce will become low due to
severe external fragmentation.
------ UPTIME (uptime) ------
up time: 33 days, 08:10:58
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 2792568 kB
MemFree: 37340 kB
Buffers: 13412 kB
Cached: 655456 kB
------ PAGETYPEINFO (/proc/pagetypeinfo) ------
Free pages count per migrate type at order 0 1 2 3 4
Node 0, zone DMA, type Unmovable 718 628 1116 301 0
Node 0, zone DMA, type Reclaimable 198 93 0 0 0
Node 0, zone DMA, type Movable 0 0 0 0 0
Node 0, zone DMA, type Reserve 0 0 0 0 0
Node 0, zone DMA, type CMA 89 11 3 0 0
Node 0, zone DMA, type Isolate 0 0 0 0 0
Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
Node 0, zone DMA 377 115 120 2 113 0
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
pgsteal_direct_dma 28575192
pgsteal_kswapd_dma 378357910
pgscan_kswapd_dma 422765699
pgscan_direct_dma 31860747
kswapd_low_wmark_hit_quickly 947979
kswapd_high_wmark_hit_quickly 139901
allocstall 592989
compact_migrate_scanned 149884903
compact_free_scanned 6629299888
compact_isolated 7699012
compact_stall 52550
compact_fail 45155
compact_success 6057
ChengYi He (2):
mm/page_alloc: let migration fallback support pages of requested order
mm/page_alloc: avoid splitting pages of order 2 and 3 in migration
fallback
mm/page_alloc.c | 92 ++++++++++++++++++++++++++++++++++++---------------------
1 file changed, 59 insertions(+), 33 deletions(-)
--
1.9.1
^ permalink raw reply [flat|nested] 16+ messages in thread
* [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
@ 2016-01-29 19:23 ` ChengYi He
0 siblings, 0 replies; 16+ messages in thread
From: ChengYi He @ 2016-01-29 19:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Michal Hocko, Vlastimil Babka, David Rientjes,
Joonsoo Kim, Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel, chengyihetaipei
The patchset tries to avoid external fragmentation related to migration
fallback. The symptom of this external fragmentation is that there are
lots of allocation failures of order-2 and order-3 pages and many
threads enter allocation slowpath to compact and direct reclaim pages.
This will degrade system performance and make it less responsive to
users. This symptom could be observed in devices which have only one
memory zone, such as some arm64 android devices. Below are two examples
in which processes fail to allocate order-2 and order-3 pages and enter
direct reclaim.
1) In arm64, THREAD_SIZE_ORDER is 2. The thread enters direct reclaim
while allocating an order-2 page as kernel stack.
[<ffffffc0002077dc>] dump_backtrace+0x0/0x134
[<ffffffc000207920>] show_stack+0x10/0x1c
[<ffffffc000cedc64>] dump_stack+0x1c/0x28
[<ffffffc0002cb6bc>] try_to_free_pages+0x5d8/0x704
[<ffffffc0002c219c>] __alloc_pages_nodemask+0x544/0x834
[<ffffffc00021a1e4>] copy_process.part.58+0xf4/0xdfc
[<ffffffc00021b000>] do_fork+0xe0/0x358
[<ffffffc00021b310>] SyS_clone+0x10/0x1c
2) The thread enters direct reclaim while allocating an order-3 page.
[<ffffffc0002077dc>] dump_backtrace+0x0/0x134
[<ffffffc000207920>] show_stack+0x10/0x1c
[<ffffffc000cedc64>] dump_stack+0x1c/0x28
[<ffffffc0002cb6bc>] try_to_free_pages+0x5d8/0x704
[<ffffffc0002c219c>] __alloc_pages_nodemask+0x544/0x834
[<ffffffc0002f0c68>] new_slab+0x80/0x23c
[<ffffffc0002f2780>] __slab_alloc.isra.50.constprop.55+0x26c/0x300
[<ffffffc0002f2abc>] kmem_cache_alloc+0x94/0x1d4
[<ffffffc0003e3a1c>] fuse_alloc_inode+0x20/0xb8
[<ffffffc00030f468>] alloc_inode+0x1c/0x90
[<ffffffc000310134>] iget5_locked+0xa0/0x1c0
[<ffffffc0003e3d00>] fuse_iget+0x60/0x1bc
[<ffffffc0003de13c>] fuse_lookup_name+0x140/0x194
[<ffffffc0003de1c4>] fuse_lookup+0x34/0x110
[<ffffffc00030236c>] lookup_real+0x30/0x54
[<ffffffc000302efc>] __lookup_hash+0x30/0x48
[<ffffffc00030377c>] lookup_slow+0x44/0xbc
[<ffffffc000304dd8>] path_lookupat+0x104/0x710
[<ffffffc00030540c>] filename_lookup.isra.32+0x28/0x74
[<ffffffc0003072cc>] user_path_at_empty+0x58/0x88
[<ffffffc000307308>] user_path_at+0xc/0x18
[<ffffffc0002f8764>] SyS_faccessat+0xc0/0x1bc
Below is the root cause of this external fragmentation which could be
observed in devices which have only one memory zone, such as some arm64
android devices:
1) In arm64, the first 4GB physical address space is of DMA zone. If the
size of physical memory is less than 4GB and the whole memory is in the
first 4GB address space, then the system will have only one DMA zone.
2) By default, all pageblocks are Movable.
3) Allocators such as slab, ion, graphics preferably allocate pages of
Unmvoable migration type. It might fallback to allocate Movable pages
and changes Movable pageblocks into Unmovable ones.
4) Movable pagesblocks will become less and less due to above reason.
However, in android system, AnonPages request is always high. The
Movable pages will be easily exhausted.
5) While Movable pages are exhausted, the Movable allocations will
frequently fallback to allocate the largest feasiable pages of the other
migration types. The order-2 and order-3 Unmovable pages will be split
into smaller ones easily.
This symptom doesn't appear in arm32 android which usually has two
memory zones including Highmem and Normal. The slab, ion, and graphics
allocators allocate pages with flag GFP_KERNEL. Only Movable pageblocks
in Normal zone become less, and the Movable pages in Highmem zone are
still a lot. Thus, the Movable pages will not be easily exhausted, and
there will not be frequent fallbacks.
Since the root cause is that fallbacks might frequently split order-2
and order-3 pages of the other migration types. This patch tweaks
fallback mechanism to avoid splitting order-2 and order-3 pages. while
fallbacks happen, if the largest feasible pages are less than or queal to
COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
reason why fallbacks prefer the largest feasiable pages is to increase
fallback efficiency since fallbacks are likely to happen again. By
stealing the largest feasible pages, it could reduce the oppourtunities
of antoher fallback. Besides, it could make consecutive allocations more
approximate to each other and make system less fragment. However, if the
largest feasible pages are less than or equal to order-3, fallbacks might
split it and make the upcoming order-3 page allocations fail.
My test is against arm64 android devices with kernel 3.10.49. I set the
same account and install the same applications in both deivces and use
them synchronously.
Test result:
1) Test without this patch:
Most free pages are order-0 Unmovable ones. allocstall and compact_stall
in /proc/vmstat are relatively high. And most occurances of allocstall
are due to order-2 and order-3 allocations.
2) Test with this patch:
There are more order-2 and order-3 free pages. allocstall and
compact_stall in /proc/vmstat are relatively low. And most occurances of
allocstall are due to order-0 allocations.
Log:
1) Test without this patch:
------ TIME (date) ------
Fri Jul 3 16:52:55 CST 2015
------ UPTIME (uptime) ------
up time: 2 days, 12:06:52, idle time: 8 days, 14:48:55, sleep time: 16:43:56
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 2792568 kB
MemFree: 194524 kB
Buffers: 3788 kB
Cached: 380872 kB
------ PAGETYPEINFO (/proc/pagetypeinfo) ------
Free pages count per migrate type at order 0 1 2 3 4
Node 0, zone DMA, type Unmovable 43852 701 0 0 0
Node 0, zone DMA, type Reclaimable 3357 0 0 0 0
Node 0, zone DMA, type Movable 0 5 0 0 0
Node 0, zone DMA, type Reserve 0 1 5 0 0
Node 0, zone DMA, type CMA 2 0 0 0 0
Node 0, zone DMA, type Isolate 0 0 0 0 0
Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
Node 0, zone DMA 362 80 170 2 113 0
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
pgsteal_kswapd_dma 31755040
pgsteal_direct_dma 34597394
pgscan_kswapd_dma 36427664
pgscan_direct_dma 39490711
kswapd_low_wmark_hit_quickly 201929
kswapd_high_wmark_hit_quickly 4858
allocstall 664269
allocstall_order_0 9738
allocstall_order_1 1787
allocstall_order_2 637608
allocstall_order_3 15136
pgmigrate_success 2941956
pgmigrate_fail 1033
compact_migrate_scanned 142985157
compact_free_scanned 4734040109
compact_isolated 7720362
compact_stall 65978
compact_fail 46084
compact_success 11717
2) Test with this patch:
------ TIME (date) ------
Fri Jul 3 16:52:31 CST 2015
------ UPTIME (uptime) ------
up time: 2 days, 12:06:30
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 2792568 kB
MemFree: 47612 kB
Buffers: 3732 kB
Cached: 387048 kB
------ PAGETYPEINFO (/proc/pagetypeinfo) ------
Free pages count per migrate type at order 0 1 2 3 4
Node 0, zone DMA, type Unmovable 272 243 126 1 0
Node 0, zone DMA, type Reclaimable 0 361 168 46 0
Node 0, zone DMA, type Movable 4103 1782 130 3 0
Node 0, zone DMA, type Reserve 0 0 0 0 0
Node 0, zone DMA, type CMA 563 2 0 0 0
Node 0, zone DMA, type Isolate 0 0 0 0 0
Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
Node 0, zone DMA 183 12 417 2 113 0
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
pgsteal_kswapd_dma 50710868
pgsteal_direct_dma 1756780
pgscan_kswapd_dma 58281837
pgscan_direct_dma 2022049
kswapd_low_wmark_hit_quickly 37599
kswapd_high_wmark_hit_quickly 13564
allocstall 27510
allocstall_order_0 26101
allocstall_order_1 23
allocstall_order_2 1224
allocstall_order_3 162
pgmigrate_success 63751
pgmigrate_fail 7
compact_migrate_scanned 278170
compact_free_scanned 6155410
compact_isolated 140762
compact_stall 749
compact_fail 54
compact_success 22
unevictable_pgs_culled 794
Below is the status of another device with this patch.
/proc/pagetypeinfo shows that even if there are no Movable pages, there
are lots of order-2 and order-3 Unmovable pages. For this case, if the
patch is not applied, then order-2 and order-3 Unmovable pages will be
split easily. It's likely that system perforamnce will become low due to
severe external fragmentation.
------ UPTIME (uptime) ------
up time: 33 days, 08:10:58
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 2792568 kB
MemFree: 37340 kB
Buffers: 13412 kB
Cached: 655456 kB
------ PAGETYPEINFO (/proc/pagetypeinfo) ------
Free pages count per migrate type at order 0 1 2 3 4
Node 0, zone DMA, type Unmovable 718 628 1116 301 0
Node 0, zone DMA, type Reclaimable 198 93 0 0 0
Node 0, zone DMA, type Movable 0 0 0 0 0
Node 0, zone DMA, type Reserve 0 0 0 0 0
Node 0, zone DMA, type CMA 89 11 3 0 0
Node 0, zone DMA, type Isolate 0 0 0 0 0
Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
Node 0, zone DMA 377 115 120 2 113 0
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
pgsteal_direct_dma 28575192
pgsteal_kswapd_dma 378357910
pgscan_kswapd_dma 422765699
pgscan_direct_dma 31860747
kswapd_low_wmark_hit_quickly 947979
kswapd_high_wmark_hit_quickly 139901
allocstall 592989
compact_migrate_scanned 149884903
compact_free_scanned 6629299888
compact_isolated 7699012
compact_stall 52550
compact_fail 45155
compact_success 6057
ChengYi He (2):
mm/page_alloc: let migration fallback support pages of requested order
mm/page_alloc: avoid splitting pages of order 2 and 3 in migration
fallback
mm/page_alloc.c | 92 ++++++++++++++++++++++++++++++++++++---------------------
1 file changed, 59 insertions(+), 33 deletions(-)
--
1.9.1
--
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] 16+ messages in thread
* [RFC PATCH 1/2] mm/page_alloc: let migration fallback support pages of requested order
2016-01-29 19:23 ` ChengYi He
@ 2016-01-29 19:24 ` ChengYi He
-1 siblings, 0 replies; 16+ messages in thread
From: ChengYi He @ 2016-01-29 19:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Michal Hocko, Vlastimil Babka, David Rientjes,
Joonsoo Kim, Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel, chengyihetaipei
This helper function only factors out the code flow within each order
during fallback. There is no function change.
Signed-off-by: ChengYi He <chengyihetaipei@gmail.com>
---
mm/page_alloc.c | 79 +++++++++++++++++++++++++++++++++------------------------
1 file changed, 46 insertions(+), 33 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 63358d9..50c325a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1752,51 +1752,64 @@ static void unreserve_highatomic_pageblock(const struct alloc_context *ac)
}
}
-/* Remove an element from the buddy allocator from the fallback list */
static inline struct page *
-__rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
+__rmqueue_fallback_order(struct zone *zone, unsigned int order,
+ int start_migratetype, int current_order)
{
struct free_area *area;
- unsigned int current_order;
struct page *page;
int fallback_mt;
bool can_steal;
- /* Find the largest possible block of pages in the other list */
- for (current_order = MAX_ORDER-1;
- current_order >= order && current_order <= MAX_ORDER-1;
- --current_order) {
- area = &(zone->free_area[current_order]);
- fallback_mt = find_suitable_fallback(area, current_order,
- start_migratetype, false, &can_steal);
- if (fallback_mt == -1)
- continue;
+ area = &(zone->free_area[current_order]);
+ fallback_mt = find_suitable_fallback(area, current_order,
+ start_migratetype, false, &can_steal);
+ if (fallback_mt == -1)
+ return NULL;
- page = list_first_entry(&area->free_list[fallback_mt],
- struct page, lru);
- if (can_steal)
- steal_suitable_fallback(zone, page, start_migratetype);
+ page = list_first_entry(&area->free_list[fallback_mt],
+ struct page, lru);
+ if (can_steal)
+ steal_suitable_fallback(zone, page, start_migratetype);
- /* Remove the page from the freelists */
- area->nr_free--;
- list_del(&page->lru);
- rmv_page_order(page);
+ /* Remove the page from the freelists */
+ area->nr_free--;
+ list_del(&page->lru);
+ rmv_page_order(page);
- expand(zone, page, order, current_order, area,
- start_migratetype);
- /*
- * The pcppage_migratetype may differ from pageblock's
- * migratetype depending on the decisions in
- * find_suitable_fallback(). This is OK as long as it does not
- * differ for MIGRATE_CMA pageblocks. Those can be used as
- * fallback only via special __rmqueue_cma_fallback() function
- */
- set_pcppage_migratetype(page, start_migratetype);
+ expand(zone, page, order, current_order, area,
+ start_migratetype);
+ /*
+ * The pcppage_migratetype may differ from pageblock's
+ * migratetype depending on the decisions in
+ * find_suitable_fallback(). This is OK as long as it does not
+ * differ for MIGRATE_CMA pageblocks. Those can be used as
+ * fallback only via special __rmqueue_cma_fallback() function
+ */
+ set_pcppage_migratetype(page, start_migratetype);
- trace_mm_page_alloc_extfrag(page, order, current_order,
- start_migratetype, fallback_mt);
+ trace_mm_page_alloc_extfrag(page, order, current_order,
+ start_migratetype, fallback_mt);
- return page;
+ return page;
+}
+
+/* Remove an element from the buddy allocator from the fallback list */
+static inline struct page *
+__rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
+{
+ unsigned int current_order;
+ struct page *page;
+
+ /* Find the largest possible block of pages in the other list */
+ for (current_order = MAX_ORDER-1;
+ current_order >= order && current_order <= MAX_ORDER-1;
+ --current_order) {
+ page = __rmqueue_fallback_order(zone, order, start_migratetype,
+ current_order);
+
+ if (page)
+ return page;
}
return NULL;
--
1.9.1
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [RFC PATCH 1/2] mm/page_alloc: let migration fallback support pages of requested order
@ 2016-01-29 19:24 ` ChengYi He
0 siblings, 0 replies; 16+ messages in thread
From: ChengYi He @ 2016-01-29 19:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Michal Hocko, Vlastimil Babka, David Rientjes,
Joonsoo Kim, Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel, chengyihetaipei
This helper function only factors out the code flow within each order
during fallback. There is no function change.
Signed-off-by: ChengYi He <chengyihetaipei@gmail.com>
---
mm/page_alloc.c | 79 +++++++++++++++++++++++++++++++++------------------------
1 file changed, 46 insertions(+), 33 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 63358d9..50c325a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1752,51 +1752,64 @@ static void unreserve_highatomic_pageblock(const struct alloc_context *ac)
}
}
-/* Remove an element from the buddy allocator from the fallback list */
static inline struct page *
-__rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
+__rmqueue_fallback_order(struct zone *zone, unsigned int order,
+ int start_migratetype, int current_order)
{
struct free_area *area;
- unsigned int current_order;
struct page *page;
int fallback_mt;
bool can_steal;
- /* Find the largest possible block of pages in the other list */
- for (current_order = MAX_ORDER-1;
- current_order >= order && current_order <= MAX_ORDER-1;
- --current_order) {
- area = &(zone->free_area[current_order]);
- fallback_mt = find_suitable_fallback(area, current_order,
- start_migratetype, false, &can_steal);
- if (fallback_mt == -1)
- continue;
+ area = &(zone->free_area[current_order]);
+ fallback_mt = find_suitable_fallback(area, current_order,
+ start_migratetype, false, &can_steal);
+ if (fallback_mt == -1)
+ return NULL;
- page = list_first_entry(&area->free_list[fallback_mt],
- struct page, lru);
- if (can_steal)
- steal_suitable_fallback(zone, page, start_migratetype);
+ page = list_first_entry(&area->free_list[fallback_mt],
+ struct page, lru);
+ if (can_steal)
+ steal_suitable_fallback(zone, page, start_migratetype);
- /* Remove the page from the freelists */
- area->nr_free--;
- list_del(&page->lru);
- rmv_page_order(page);
+ /* Remove the page from the freelists */
+ area->nr_free--;
+ list_del(&page->lru);
+ rmv_page_order(page);
- expand(zone, page, order, current_order, area,
- start_migratetype);
- /*
- * The pcppage_migratetype may differ from pageblock's
- * migratetype depending on the decisions in
- * find_suitable_fallback(). This is OK as long as it does not
- * differ for MIGRATE_CMA pageblocks. Those can be used as
- * fallback only via special __rmqueue_cma_fallback() function
- */
- set_pcppage_migratetype(page, start_migratetype);
+ expand(zone, page, order, current_order, area,
+ start_migratetype);
+ /*
+ * The pcppage_migratetype may differ from pageblock's
+ * migratetype depending on the decisions in
+ * find_suitable_fallback(). This is OK as long as it does not
+ * differ for MIGRATE_CMA pageblocks. Those can be used as
+ * fallback only via special __rmqueue_cma_fallback() function
+ */
+ set_pcppage_migratetype(page, start_migratetype);
- trace_mm_page_alloc_extfrag(page, order, current_order,
- start_migratetype, fallback_mt);
+ trace_mm_page_alloc_extfrag(page, order, current_order,
+ start_migratetype, fallback_mt);
- return page;
+ return page;
+}
+
+/* Remove an element from the buddy allocator from the fallback list */
+static inline struct page *
+__rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
+{
+ unsigned int current_order;
+ struct page *page;
+
+ /* Find the largest possible block of pages in the other list */
+ for (current_order = MAX_ORDER-1;
+ current_order >= order && current_order <= MAX_ORDER-1;
+ --current_order) {
+ page = __rmqueue_fallback_order(zone, order, start_migratetype,
+ current_order);
+
+ if (page)
+ return page;
}
return NULL;
--
1.9.1
--
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 related [flat|nested] 16+ messages in thread
* [RFC PATCH 2/2] mm/page_alloc: avoid splitting pages of order 2 and 3 in migration fallback
2016-01-29 19:23 ` ChengYi He
@ 2016-01-29 19:25 ` ChengYi He
-1 siblings, 0 replies; 16+ messages in thread
From: ChengYi He @ 2016-01-29 19:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Michal Hocko, Vlastimil Babka, David Rientjes,
Joonsoo Kim, Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel, chengyihetaipei
While buddy system fallbacks to allocate different migration type pages,
it prefers the largest feasible pages and might split the chosen page
into smalller ones. If the largest feasible pages are less than or equal
to orde-3 and migration fallback happens frequently, then order-2 and
order-3 pages can be exhausted easily. This patch aims to allocate the
smallest feasible pages for the fallback mechanism under this condition.
Signed-off-by: ChengYi He <chengyihetaipei@gmail.com>
---
mm/page_alloc.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 50c325a..3fcb653 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1802,9 +1802,22 @@ __rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
struct page *page;
/* Find the largest possible block of pages in the other list */
- for (current_order = MAX_ORDER-1;
- current_order >= order && current_order <= MAX_ORDER-1;
- --current_order) {
+ for (current_order = MAX_ORDER - 1;
+ current_order >= max_t(unsigned int, PAGE_ALLOC_COSTLY_ORDER + 1, order);
+ --current_order) {
+ page = __rmqueue_fallback_order(zone, order, start_migratetype,
+ current_order);
+
+ if (page)
+ return page;
+ }
+
+ /*
+ * While current_order <= PAGE_ALLOC_COSTLY_ORDER, find the smallest
+ * feasible pages in the other list to avoid splitting high order pages
+ */
+ for (current_order = order; current_order <= PAGE_ALLOC_COSTLY_ORDER;
+ ++current_order) {
page = __rmqueue_fallback_order(zone, order, start_migratetype,
current_order);
--
1.9.1
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [RFC PATCH 2/2] mm/page_alloc: avoid splitting pages of order 2 and 3 in migration fallback
@ 2016-01-29 19:25 ` ChengYi He
0 siblings, 0 replies; 16+ messages in thread
From: ChengYi He @ 2016-01-29 19:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Michal Hocko, Vlastimil Babka, David Rientjes,
Joonsoo Kim, Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel, chengyihetaipei
While buddy system fallbacks to allocate different migration type pages,
it prefers the largest feasible pages and might split the chosen page
into smalller ones. If the largest feasible pages are less than or equal
to orde-3 and migration fallback happens frequently, then order-2 and
order-3 pages can be exhausted easily. This patch aims to allocate the
smallest feasible pages for the fallback mechanism under this condition.
Signed-off-by: ChengYi He <chengyihetaipei@gmail.com>
---
mm/page_alloc.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 50c325a..3fcb653 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1802,9 +1802,22 @@ __rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
struct page *page;
/* Find the largest possible block of pages in the other list */
- for (current_order = MAX_ORDER-1;
- current_order >= order && current_order <= MAX_ORDER-1;
- --current_order) {
+ for (current_order = MAX_ORDER - 1;
+ current_order >= max_t(unsigned int, PAGE_ALLOC_COSTLY_ORDER + 1, order);
+ --current_order) {
+ page = __rmqueue_fallback_order(zone, order, start_migratetype,
+ current_order);
+
+ if (page)
+ return page;
+ }
+
+ /*
+ * While current_order <= PAGE_ALLOC_COSTLY_ORDER, find the smallest
+ * feasible pages in the other list to avoid splitting high order pages
+ */
+ for (current_order = order; current_order <= PAGE_ALLOC_COSTLY_ORDER;
+ ++current_order) {
page = __rmqueue_fallback_order(zone, order, start_migratetype,
current_order);
--
1.9.1
--
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 related [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
2016-01-29 19:23 ` ChengYi He
@ 2016-01-29 21:03 ` Vlastimil Babka
-1 siblings, 0 replies; 16+ messages in thread
From: Vlastimil Babka @ 2016-01-29 21:03 UTC (permalink / raw)
To: ChengYi He, Andrew Morton
Cc: Mel Gorman, Michal Hocko, David Rientjes, Joonsoo Kim,
Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On 01/29/2016 08:23 PM, ChengYi He wrote:
[...]
> Below is the root cause of this external fragmentation which could be
> observed in devices which have only one memory zone, such as some arm64
> android devices:
>
> 1) In arm64, the first 4GB physical address space is of DMA zone. If the
> size of physical memory is less than 4GB and the whole memory is in the
> first 4GB address space, then the system will have only one DMA zone.
> 2) By default, all pageblocks are Movable.
> 3) Allocators such as slab, ion, graphics preferably allocate pages of
> Unmvoable migration type. It might fallback to allocate Movable pages
> and changes Movable pageblocks into Unmovable ones.
> 4) Movable pagesblocks will become less and less due to above reason.
> However, in android system, AnonPages request is always high. The
> Movable pages will be easily exhausted.
> 5) While Movable pages are exhausted, the Movable allocations will
> frequently fallback to allocate the largest feasiable pages of the other
> migration types. The order-2 and order-3 Unmovable pages will be split
> into smaller ones easily.
>
> This symptom doesn't appear in arm32 android which usually has two
> memory zones including Highmem and Normal. The slab, ion, and graphics
> allocators allocate pages with flag GFP_KERNEL. Only Movable pageblocks
> in Normal zone become less, and the Movable pages in Highmem zone are
> still a lot. Thus, the Movable pages will not be easily exhausted, and
> there will not be frequent fallbacks.
Hm, this 1 zone vs 2 zones shouldn't make that much difference, unless
a) you use zone reclaim mode, or b) you have an old kernel without fair
zone allocation policy?
> Since the root cause is that fallbacks might frequently split order-2
> and order-3 pages of the other migration types. This patch tweaks
> fallback mechanism to avoid splitting order-2 and order-3 pages. while
> fallbacks happen, if the largest feasible pages are less than or queal to
> COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
> reason why fallbacks prefer the largest feasiable pages is to increase
> fallback efficiency since fallbacks are likely to happen again. By
> stealing the largest feasible pages, it could reduce the oppourtunities
> of antoher fallback. Besides, it could make consecutive allocations more
> approximate to each other and make system less fragment. However, if the
> largest feasible pages are less than or equal to order-3, fallbacks might
> split it and make the upcoming order-3 page allocations fail.
In theory I don't see immediately why preferring smaller pages for
fallback should be a clear win. If it's Unmovable allocations stealing
from Movable pageblocks, the allocations will spread over larger areas
instead of being grouped together. Maybe, for Movable allocations
stealing from Unmovable allocations, preferring smallest might make
sense and be safe, as any extra fragmentation is fixable bycompaction.
Maybe it was already tried (by Joonsoo?) at some point, I'm not sure
right now.
> My test is against arm64 android devices with kernel 3.10.49. I set the
> same account and install the same applications in both deivces and use
> them synchronously.
3.10 is wayyyyyy old. There were numerous patches to compaction and
anti-fragmentation since then. IIRC the fallback decisions were quite
suboptimal at that point. I'm not even sure how you could apply your
patches to both recent kernel for posting them, and 3.10 for testing?
Is it possible to test on 4.4?
>
> Test result:
> 1) Test without this patch:
> Most free pages are order-0 Unmovable ones. allocstall and compact_stall
> in /proc/vmstat are relatively high. And most occurances of allocstall
> are due to order-2 and order-3 allocations.
> 2) Test with this patch:
> There are more order-2 and order-3 free pages. allocstall and
> compact_stall in /proc/vmstat are relatively low. And most occurances of
> allocstall are due to order-0 allocations.
>
> Log:
> 1) Test without this patch:
> ------ TIME (date) ------
> Fri Jul 3 16:52:55 CST 2015
> ------ UPTIME (uptime) ------
> up time: 2 days, 12:06:52, idle time: 8 days, 14:48:55, sleep time: 16:43:56
> ------ MEMORY INFO (/proc/meminfo) ------
> MemTotal: 2792568 kB
> MemFree: 194524 kB
> Buffers: 3788 kB
> Cached: 380872 kB
> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
> Free pages count per migrate type at order 0 1 2 3 4
> Node 0, zone DMA, type Unmovable 43852 701 0 0 0
> Node 0, zone DMA, type Reclaimable 3357 0 0 0 0
> Node 0, zone DMA, type Movable 0 5 0 0 0
> Node 0, zone DMA, type Reserve 0 1 5 0 0
> Node 0, zone DMA, type CMA 2 0 0 0 0
> Node 0, zone DMA, type Isolate 0 0 0 0 0
> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
> Node 0, zone DMA 362 80 170 2 113 0
> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
> pgsteal_kswapd_dma 31755040
> pgsteal_direct_dma 34597394
> pgscan_kswapd_dma 36427664
> pgscan_direct_dma 39490711
> kswapd_low_wmark_hit_quickly 201929
> kswapd_high_wmark_hit_quickly 4858
> allocstall 664269
> allocstall_order_0 9738
> allocstall_order_1 1787
> allocstall_order_2 637608
> allocstall_order_3 15136
> pgmigrate_success 2941956
> pgmigrate_fail 1033
> compact_migrate_scanned 142985157
> compact_free_scanned 4734040109
> compact_isolated 7720362
> compact_stall 65978
> compact_fail 46084
> compact_success 11717
>
> 2) Test with this patch:
> ------ TIME (date) ------
> Fri Jul 3 16:52:31 CST 2015
> ------ UPTIME (uptime) ------
> up time: 2 days, 12:06:30
> ------ MEMORY INFO (/proc/meminfo) ------
> MemTotal: 2792568 kB
> MemFree: 47612 kB
> Buffers: 3732 kB
> Cached: 387048 kB
> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
> Free pages count per migrate type at order 0 1 2 3 4
> Node 0, zone DMA, type Unmovable 272 243 126 1 0
> Node 0, zone DMA, type Reclaimable 0 361 168 46 0
> Node 0, zone DMA, type Movable 4103 1782 130 3 0
> Node 0, zone DMA, type Reserve 0 0 0 0 0
> Node 0, zone DMA, type CMA 563 2 0 0 0
> Node 0, zone DMA, type Isolate 0 0 0 0 0
> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
> Node 0, zone DMA 183 12 417 2 113 0
> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
> pgsteal_kswapd_dma 50710868
> pgsteal_direct_dma 1756780
> pgscan_kswapd_dma 58281837
> pgscan_direct_dma 2022049
> kswapd_low_wmark_hit_quickly 37599
> kswapd_high_wmark_hit_quickly 13564
> allocstall 27510
> allocstall_order_0 26101
> allocstall_order_1 23
> allocstall_order_2 1224
> allocstall_order_3 162
> pgmigrate_success 63751
> pgmigrate_fail 7
> compact_migrate_scanned 278170
> compact_free_scanned 6155410
> compact_isolated 140762
> compact_stall 749
> compact_fail 54
> compact_success 22
> unevictable_pgs_culled 794
>
> Below is the status of another device with this patch.
> /proc/pagetypeinfo shows that even if there are no Movable pages, there
> are lots of order-2 and order-3 Unmovable pages. For this case, if the
> patch is not applied, then order-2 and order-3 Unmovable pages will be
> split easily. It's likely that system perforamnce will become low due to
> severe external fragmentation.
>
> ------ UPTIME (uptime) ------
> up time: 33 days, 08:10:58
> ------ MEMORY INFO (/proc/meminfo) ------
> MemTotal: 2792568 kB
> MemFree: 37340 kB
> Buffers: 13412 kB
> Cached: 655456 kB
> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
> Free pages count per migrate type at order 0 1 2 3 4
> Node 0, zone DMA, type Unmovable 718 628 1116 301 0
> Node 0, zone DMA, type Reclaimable 198 93 0 0 0
> Node 0, zone DMA, type Movable 0 0 0 0 0
> Node 0, zone DMA, type Reserve 0 0 0 0 0
> Node 0, zone DMA, type CMA 89 11 3 0 0
> Node 0, zone DMA, type Isolate 0 0 0 0 0
> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
> Node 0, zone DMA 377 115 120 2 113 0
> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
> pgsteal_direct_dma 28575192
> pgsteal_kswapd_dma 378357910
> pgscan_kswapd_dma 422765699
> pgscan_direct_dma 31860747
> kswapd_low_wmark_hit_quickly 947979
> kswapd_high_wmark_hit_quickly 139901
> allocstall 592989
> compact_migrate_scanned 149884903
> compact_free_scanned 6629299888
> compact_isolated 7699012
> compact_stall 52550
> compact_fail 45155
> compact_success 6057
>
> ChengYi He (2):
> mm/page_alloc: let migration fallback support pages of requested order
> mm/page_alloc: avoid splitting pages of order 2 and 3 in migration
> fallback
>
> mm/page_alloc.c | 92 ++++++++++++++++++++++++++++++++++++---------------------
> 1 file changed, 59 insertions(+), 33 deletions(-)
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
@ 2016-01-29 21:03 ` Vlastimil Babka
0 siblings, 0 replies; 16+ messages in thread
From: Vlastimil Babka @ 2016-01-29 21:03 UTC (permalink / raw)
To: ChengYi He, Andrew Morton
Cc: Mel Gorman, Michal Hocko, David Rientjes, Joonsoo Kim,
Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On 01/29/2016 08:23 PM, ChengYi He wrote:
[...]
> Below is the root cause of this external fragmentation which could be
> observed in devices which have only one memory zone, such as some arm64
> android devices:
>
> 1) In arm64, the first 4GB physical address space is of DMA zone. If the
> size of physical memory is less than 4GB and the whole memory is in the
> first 4GB address space, then the system will have only one DMA zone.
> 2) By default, all pageblocks are Movable.
> 3) Allocators such as slab, ion, graphics preferably allocate pages of
> Unmvoable migration type. It might fallback to allocate Movable pages
> and changes Movable pageblocks into Unmovable ones.
> 4) Movable pagesblocks will become less and less due to above reason.
> However, in android system, AnonPages request is always high. The
> Movable pages will be easily exhausted.
> 5) While Movable pages are exhausted, the Movable allocations will
> frequently fallback to allocate the largest feasiable pages of the other
> migration types. The order-2 and order-3 Unmovable pages will be split
> into smaller ones easily.
>
> This symptom doesn't appear in arm32 android which usually has two
> memory zones including Highmem and Normal. The slab, ion, and graphics
> allocators allocate pages with flag GFP_KERNEL. Only Movable pageblocks
> in Normal zone become less, and the Movable pages in Highmem zone are
> still a lot. Thus, the Movable pages will not be easily exhausted, and
> there will not be frequent fallbacks.
Hm, this 1 zone vs 2 zones shouldn't make that much difference, unless
a) you use zone reclaim mode, or b) you have an old kernel without fair
zone allocation policy?
> Since the root cause is that fallbacks might frequently split order-2
> and order-3 pages of the other migration types. This patch tweaks
> fallback mechanism to avoid splitting order-2 and order-3 pages. while
> fallbacks happen, if the largest feasible pages are less than or queal to
> COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
> reason why fallbacks prefer the largest feasiable pages is to increase
> fallback efficiency since fallbacks are likely to happen again. By
> stealing the largest feasible pages, it could reduce the oppourtunities
> of antoher fallback. Besides, it could make consecutive allocations more
> approximate to each other and make system less fragment. However, if the
> largest feasible pages are less than or equal to order-3, fallbacks might
> split it and make the upcoming order-3 page allocations fail.
In theory I don't see immediately why preferring smaller pages for
fallback should be a clear win. If it's Unmovable allocations stealing
from Movable pageblocks, the allocations will spread over larger areas
instead of being grouped together. Maybe, for Movable allocations
stealing from Unmovable allocations, preferring smallest might make
sense and be safe, as any extra fragmentation is fixable bycompaction.
Maybe it was already tried (by Joonsoo?) at some point, I'm not sure
right now.
> My test is against arm64 android devices with kernel 3.10.49. I set the
> same account and install the same applications in both deivces and use
> them synchronously.
3.10 is wayyyyyy old. There were numerous patches to compaction and
anti-fragmentation since then. IIRC the fallback decisions were quite
suboptimal at that point. I'm not even sure how you could apply your
patches to both recent kernel for posting them, and 3.10 for testing?
Is it possible to test on 4.4?
>
> Test result:
> 1) Test without this patch:
> Most free pages are order-0 Unmovable ones. allocstall and compact_stall
> in /proc/vmstat are relatively high. And most occurances of allocstall
> are due to order-2 and order-3 allocations.
> 2) Test with this patch:
> There are more order-2 and order-3 free pages. allocstall and
> compact_stall in /proc/vmstat are relatively low. And most occurances of
> allocstall are due to order-0 allocations.
>
> Log:
> 1) Test without this patch:
> ------ TIME (date) ------
> Fri Jul 3 16:52:55 CST 2015
> ------ UPTIME (uptime) ------
> up time: 2 days, 12:06:52, idle time: 8 days, 14:48:55, sleep time: 16:43:56
> ------ MEMORY INFO (/proc/meminfo) ------
> MemTotal: 2792568 kB
> MemFree: 194524 kB
> Buffers: 3788 kB
> Cached: 380872 kB
> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
> Free pages count per migrate type at order 0 1 2 3 4
> Node 0, zone DMA, type Unmovable 43852 701 0 0 0
> Node 0, zone DMA, type Reclaimable 3357 0 0 0 0
> Node 0, zone DMA, type Movable 0 5 0 0 0
> Node 0, zone DMA, type Reserve 0 1 5 0 0
> Node 0, zone DMA, type CMA 2 0 0 0 0
> Node 0, zone DMA, type Isolate 0 0 0 0 0
> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
> Node 0, zone DMA 362 80 170 2 113 0
> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
> pgsteal_kswapd_dma 31755040
> pgsteal_direct_dma 34597394
> pgscan_kswapd_dma 36427664
> pgscan_direct_dma 39490711
> kswapd_low_wmark_hit_quickly 201929
> kswapd_high_wmark_hit_quickly 4858
> allocstall 664269
> allocstall_order_0 9738
> allocstall_order_1 1787
> allocstall_order_2 637608
> allocstall_order_3 15136
> pgmigrate_success 2941956
> pgmigrate_fail 1033
> compact_migrate_scanned 142985157
> compact_free_scanned 4734040109
> compact_isolated 7720362
> compact_stall 65978
> compact_fail 46084
> compact_success 11717
>
> 2) Test with this patch:
> ------ TIME (date) ------
> Fri Jul 3 16:52:31 CST 2015
> ------ UPTIME (uptime) ------
> up time: 2 days, 12:06:30
> ------ MEMORY INFO (/proc/meminfo) ------
> MemTotal: 2792568 kB
> MemFree: 47612 kB
> Buffers: 3732 kB
> Cached: 387048 kB
> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
> Free pages count per migrate type at order 0 1 2 3 4
> Node 0, zone DMA, type Unmovable 272 243 126 1 0
> Node 0, zone DMA, type Reclaimable 0 361 168 46 0
> Node 0, zone DMA, type Movable 4103 1782 130 3 0
> Node 0, zone DMA, type Reserve 0 0 0 0 0
> Node 0, zone DMA, type CMA 563 2 0 0 0
> Node 0, zone DMA, type Isolate 0 0 0 0 0
> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
> Node 0, zone DMA 183 12 417 2 113 0
> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
> pgsteal_kswapd_dma 50710868
> pgsteal_direct_dma 1756780
> pgscan_kswapd_dma 58281837
> pgscan_direct_dma 2022049
> kswapd_low_wmark_hit_quickly 37599
> kswapd_high_wmark_hit_quickly 13564
> allocstall 27510
> allocstall_order_0 26101
> allocstall_order_1 23
> allocstall_order_2 1224
> allocstall_order_3 162
> pgmigrate_success 63751
> pgmigrate_fail 7
> compact_migrate_scanned 278170
> compact_free_scanned 6155410
> compact_isolated 140762
> compact_stall 749
> compact_fail 54
> compact_success 22
> unevictable_pgs_culled 794
>
> Below is the status of another device with this patch.
> /proc/pagetypeinfo shows that even if there are no Movable pages, there
> are lots of order-2 and order-3 Unmovable pages. For this case, if the
> patch is not applied, then order-2 and order-3 Unmovable pages will be
> split easily. It's likely that system perforamnce will become low due to
> severe external fragmentation.
>
> ------ UPTIME (uptime) ------
> up time: 33 days, 08:10:58
> ------ MEMORY INFO (/proc/meminfo) ------
> MemTotal: 2792568 kB
> MemFree: 37340 kB
> Buffers: 13412 kB
> Cached: 655456 kB
> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
> Free pages count per migrate type at order 0 1 2 3 4
> Node 0, zone DMA, type Unmovable 718 628 1116 301 0
> Node 0, zone DMA, type Reclaimable 198 93 0 0 0
> Node 0, zone DMA, type Movable 0 0 0 0 0
> Node 0, zone DMA, type Reserve 0 0 0 0 0
> Node 0, zone DMA, type CMA 89 11 3 0 0
> Node 0, zone DMA, type Isolate 0 0 0 0 0
> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
> Node 0, zone DMA 377 115 120 2 113 0
> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
> pgsteal_direct_dma 28575192
> pgsteal_kswapd_dma 378357910
> pgscan_kswapd_dma 422765699
> pgscan_direct_dma 31860747
> kswapd_low_wmark_hit_quickly 947979
> kswapd_high_wmark_hit_quickly 139901
> allocstall 592989
> compact_migrate_scanned 149884903
> compact_free_scanned 6629299888
> compact_isolated 7699012
> compact_stall 52550
> compact_fail 45155
> compact_success 6057
>
> ChengYi He (2):
> mm/page_alloc: let migration fallback support pages of requested order
> mm/page_alloc: avoid splitting pages of order 2 and 3 in migration
> fallback
>
> mm/page_alloc.c | 92 ++++++++++++++++++++++++++++++++++++---------------------
> 1 file changed, 59 insertions(+), 33 deletions(-)
>
--
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] 16+ messages in thread
* Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
2016-01-29 21:03 ` Vlastimil Babka
@ 2016-01-30 10:21 ` Xishi Qiu
-1 siblings, 0 replies; 16+ messages in thread
From: Xishi Qiu @ 2016-01-30 10:21 UTC (permalink / raw)
To: Vlastimil Babka
Cc: ChengYi He, Andrew Morton, Mel Gorman, Michal Hocko,
David Rientjes, Joonsoo Kim, Yaowei Bai, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On 2016/1/30 5:03, Vlastimil Babka wrote:
> On 01/29/2016 08:23 PM, ChengYi He wrote:
>
> [...]
>
>> Below is the root cause of this external fragmentation which could be
>> observed in devices which have only one memory zone, such as some arm64
>> android devices:
>>
>> 1) In arm64, the first 4GB physical address space is of DMA zone. If the
>> size of physical memory is less than 4GB and the whole memory is in the
>> first 4GB address space, then the system will have only one DMA zone.
>> 2) By default, all pageblocks are Movable.
>> 3) Allocators such as slab, ion, graphics preferably allocate pages of
>> Unmvoable migration type. It might fallback to allocate Movable pages
>> and changes Movable pageblocks into Unmovable ones.
>> 4) Movable pagesblocks will become less and less due to above reason.
>> However, in android system, AnonPages request is always high. The
>> Movable pages will be easily exhausted.
>> 5) While Movable pages are exhausted, the Movable allocations will
>> frequently fallback to allocate the largest feasiable pages of the other
>> migration types. The order-2 and order-3 Unmovable pages will be split
>> into smaller ones easily.
>>
>> This symptom doesn't appear in arm32 android which usually has two
>> memory zones including Highmem and Normal. The slab, ion, and graphics
>> allocators allocate pages with flag GFP_KERNEL. Only Movable pageblocks
>> in Normal zone become less, and the Movable pages in Highmem zone are
>> still a lot. Thus, the Movable pages will not be easily exhausted, and
>> there will not be frequent fallbacks.
>
> Hm, this 1 zone vs 2 zones shouldn't make that much difference, unless
> a) you use zone reclaim mode, or b) you have an old kernel without fair
> zone allocation policy?
>
Hi Vlastimil,
I agree with you.
I think if we have a normal zone and a movable zone, then the effect of
compaction will be better.
e.g.
U: unmovable page
M: movable page
F: free page
one zone(DMA):
paddr: 0 max
ZONE_DMA: U M F U M F ... U M F U M F
after compact: U F F U F F ... U M M U M M
two zone(DMA and MOVABLE)
paddr: 0 max
ZONE_DMA: the same as above
ZONE_MOVABLE: M F M F M F ... M F M F M F
after compact: F F F F F F ... M M M M M M // we get large block than above
>> Since the root cause is that fallbacks might frequently split order-2
>> and order-3 pages of the other migration types. This patch tweaks
>> fallback mechanism to avoid splitting order-2 and order-3 pages. while
>> fallbacks happen, if the largest feasible pages are less than or queal to
>> COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
>> reason why fallbacks prefer the largest feasiable pages is to increase
>> fallback efficiency since fallbacks are likely to happen again. By
>> stealing the largest feasible pages, it could reduce the oppourtunities
>> of antoher fallback. Besides, it could make consecutive allocations more
>> approximate to each other and make system less fragment. However, if the
>> largest feasible pages are less than or equal to order-3, fallbacks might
>> split it and make the upcoming order-3 page allocations fail.
>
> In theory I don't see immediately why preferring smaller pages for
> fallback should be a clear win. If it's Unmovable allocations stealing
> from Movable pageblocks, the allocations will spread over larger areas
> instead of being grouped together. Maybe, for Movable allocations
> stealing from Unmovable allocations, preferring smallest might make
> sense and be safe, as any extra fragmentation is fixable bycompaction.
> Maybe it was already tried (by Joonsoo?) at some point, I'm not sure
> right now.
>
>> My test is against arm64 android devices with kernel 3.10.49. I set the
>> same account and install the same applications in both deivces and use
>> them synchronously.
>
> 3.10 is wayyyyyy old. There were numerous patches to compaction and
> anti-fragmentation since then. IIRC the fallback decisions were quite
> suboptimal at that point. I'm not even sure how you could apply your
> patches to both recent kernel for posting them, and 3.10 for testing?
> Is it possible to test on 4.4?
>
I think it's hard to update the drivers on android smart phone.
Thanks,
Xishi Qiu
>>
>> Test result:
>> 1) Test without this patch:
>> Most free pages are order-0 Unmovable ones. allocstall and compact_stall
>> in /proc/vmstat are relatively high. And most occurances of allocstall
>> are due to order-2 and order-3 allocations.
>> 2) Test with this patch:
>> There are more order-2 and order-3 free pages. allocstall and
>> compact_stall in /proc/vmstat are relatively low. And most occurances of
>> allocstall are due to order-0 allocations.
>>
>> Log:
>> 1) Test without this patch:
>> ------ TIME (date) ------
>> Fri Jul 3 16:52:55 CST 2015
>> ------ UPTIME (uptime) ------
>> up time: 2 days, 12:06:52, idle time: 8 days, 14:48:55, sleep time: 16:43:56
>> ------ MEMORY INFO (/proc/meminfo) ------
>> MemTotal: 2792568 kB
>> MemFree: 194524 kB
>> Buffers: 3788 kB
>> Cached: 380872 kB
>> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
>> Free pages count per migrate type at order 0 1 2 3 4
>> Node 0, zone DMA, type Unmovable 43852 701 0 0 0
>> Node 0, zone DMA, type Reclaimable 3357 0 0 0 0
>> Node 0, zone DMA, type Movable 0 5 0 0 0
>> Node 0, zone DMA, type Reserve 0 1 5 0 0
>> Node 0, zone DMA, type CMA 2 0 0 0 0
>> Node 0, zone DMA, type Isolate 0 0 0 0 0
>> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
>> Node 0, zone DMA 362 80 170 2 113 0
>> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
>> pgsteal_kswapd_dma 31755040
>> pgsteal_direct_dma 34597394
>> pgscan_kswapd_dma 36427664
>> pgscan_direct_dma 39490711
>> kswapd_low_wmark_hit_quickly 201929
>> kswapd_high_wmark_hit_quickly 4858
>> allocstall 664269
>> allocstall_order_0 9738
>> allocstall_order_1 1787
>> allocstall_order_2 637608
>> allocstall_order_3 15136
>> pgmigrate_success 2941956
>> pgmigrate_fail 1033
>> compact_migrate_scanned 142985157
>> compact_free_scanned 4734040109
>> compact_isolated 7720362
>> compact_stall 65978
>> compact_fail 46084
>> compact_success 11717
>>
>> 2) Test with this patch:
>> ------ TIME (date) ------
>> Fri Jul 3 16:52:31 CST 2015
>> ------ UPTIME (uptime) ------
>> up time: 2 days, 12:06:30
>> ------ MEMORY INFO (/proc/meminfo) ------
>> MemTotal: 2792568 kB
>> MemFree: 47612 kB
>> Buffers: 3732 kB
>> Cached: 387048 kB
>> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
>> Free pages count per migrate type at order 0 1 2 3 4
>> Node 0, zone DMA, type Unmovable 272 243 126 1 0
>> Node 0, zone DMA, type Reclaimable 0 361 168 46 0
>> Node 0, zone DMA, type Movable 4103 1782 130 3 0
>> Node 0, zone DMA, type Reserve 0 0 0 0 0
>> Node 0, zone DMA, type CMA 563 2 0 0 0
>> Node 0, zone DMA, type Isolate 0 0 0 0 0
>> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
>> Node 0, zone DMA 183 12 417 2 113 0
>> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
>> pgsteal_kswapd_dma 50710868
>> pgsteal_direct_dma 1756780
>> pgscan_kswapd_dma 58281837
>> pgscan_direct_dma 2022049
>> kswapd_low_wmark_hit_quickly 37599
>> kswapd_high_wmark_hit_quickly 13564
>> allocstall 27510
>> allocstall_order_0 26101
>> allocstall_order_1 23
>> allocstall_order_2 1224
>> allocstall_order_3 162
>> pgmigrate_success 63751
>> pgmigrate_fail 7
>> compact_migrate_scanned 278170
>> compact_free_scanned 6155410
>> compact_isolated 140762
>> compact_stall 749
>> compact_fail 54
>> compact_success 22
>> unevictable_pgs_culled 794
>>
>> Below is the status of another device with this patch.
>> /proc/pagetypeinfo shows that even if there are no Movable pages, there
>> are lots of order-2 and order-3 Unmovable pages. For this case, if the
>> patch is not applied, then order-2 and order-3 Unmovable pages will be
>> split easily. It's likely that system perforamnce will become low due to
>> severe external fragmentation.
>>
>> ------ UPTIME (uptime) ------
>> up time: 33 days, 08:10:58
>> ------ MEMORY INFO (/proc/meminfo) ------
>> MemTotal: 2792568 kB
>> MemFree: 37340 kB
>> Buffers: 13412 kB
>> Cached: 655456 kB
>> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
>> Free pages count per migrate type at order 0 1 2 3 4
>> Node 0, zone DMA, type Unmovable 718 628 1116 301 0
>> Node 0, zone DMA, type Reclaimable 198 93 0 0 0
>> Node 0, zone DMA, type Movable 0 0 0 0 0
>> Node 0, zone DMA, type Reserve 0 0 0 0 0
>> Node 0, zone DMA, type CMA 89 11 3 0 0
>> Node 0, zone DMA, type Isolate 0 0 0 0 0
>> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
>> Node 0, zone DMA 377 115 120 2 113 0
>> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
>> pgsteal_direct_dma 28575192
>> pgsteal_kswapd_dma 378357910
>> pgscan_kswapd_dma 422765699
>> pgscan_direct_dma 31860747
>> kswapd_low_wmark_hit_quickly 947979
>> kswapd_high_wmark_hit_quickly 139901
>> allocstall 592989
>> compact_migrate_scanned 149884903
>> compact_free_scanned 6629299888
>> compact_isolated 7699012
>> compact_stall 52550
>> compact_fail 45155
>> compact_success 6057
>>
>> ChengYi He (2):
>> mm/page_alloc: let migration fallback support pages of requested order
>> mm/page_alloc: avoid splitting pages of order 2 and 3 in migration
>> fallback
>>
>> mm/page_alloc.c | 92 ++++++++++++++++++++++++++++++++++++---------------------
>> 1 file changed, 59 insertions(+), 33 deletions(-)
>>
>
>
> .
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
@ 2016-01-30 10:21 ` Xishi Qiu
0 siblings, 0 replies; 16+ messages in thread
From: Xishi Qiu @ 2016-01-30 10:21 UTC (permalink / raw)
To: Vlastimil Babka
Cc: ChengYi He, Andrew Morton, Mel Gorman, Michal Hocko,
David Rientjes, Joonsoo Kim, Yaowei Bai, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On 2016/1/30 5:03, Vlastimil Babka wrote:
> On 01/29/2016 08:23 PM, ChengYi He wrote:
>
> [...]
>
>> Below is the root cause of this external fragmentation which could be
>> observed in devices which have only one memory zone, such as some arm64
>> android devices:
>>
>> 1) In arm64, the first 4GB physical address space is of DMA zone. If the
>> size of physical memory is less than 4GB and the whole memory is in the
>> first 4GB address space, then the system will have only one DMA zone.
>> 2) By default, all pageblocks are Movable.
>> 3) Allocators such as slab, ion, graphics preferably allocate pages of
>> Unmvoable migration type. It might fallback to allocate Movable pages
>> and changes Movable pageblocks into Unmovable ones.
>> 4) Movable pagesblocks will become less and less due to above reason.
>> However, in android system, AnonPages request is always high. The
>> Movable pages will be easily exhausted.
>> 5) While Movable pages are exhausted, the Movable allocations will
>> frequently fallback to allocate the largest feasiable pages of the other
>> migration types. The order-2 and order-3 Unmovable pages will be split
>> into smaller ones easily.
>>
>> This symptom doesn't appear in arm32 android which usually has two
>> memory zones including Highmem and Normal. The slab, ion, and graphics
>> allocators allocate pages with flag GFP_KERNEL. Only Movable pageblocks
>> in Normal zone become less, and the Movable pages in Highmem zone are
>> still a lot. Thus, the Movable pages will not be easily exhausted, and
>> there will not be frequent fallbacks.
>
> Hm, this 1 zone vs 2 zones shouldn't make that much difference, unless
> a) you use zone reclaim mode, or b) you have an old kernel without fair
> zone allocation policy?
>
Hi Vlastimil,
I agree with you.
I think if we have a normal zone and a movable zone, then the effect of
compaction will be better.
e.g.
U: unmovable page
M: movable page
F: free page
one zone(DMA):
paddr: 0 max
ZONE_DMA: U M F U M F ... U M F U M F
after compact: U F F U F F ... U M M U M M
two zone(DMA and MOVABLE)
paddr: 0 max
ZONE_DMA: the same as above
ZONE_MOVABLE: M F M F M F ... M F M F M F
after compact: F F F F F F ... M M M M M M // we get large block than above
>> Since the root cause is that fallbacks might frequently split order-2
>> and order-3 pages of the other migration types. This patch tweaks
>> fallback mechanism to avoid splitting order-2 and order-3 pages. while
>> fallbacks happen, if the largest feasible pages are less than or queal to
>> COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
>> reason why fallbacks prefer the largest feasiable pages is to increase
>> fallback efficiency since fallbacks are likely to happen again. By
>> stealing the largest feasible pages, it could reduce the oppourtunities
>> of antoher fallback. Besides, it could make consecutive allocations more
>> approximate to each other and make system less fragment. However, if the
>> largest feasible pages are less than or equal to order-3, fallbacks might
>> split it and make the upcoming order-3 page allocations fail.
>
> In theory I don't see immediately why preferring smaller pages for
> fallback should be a clear win. If it's Unmovable allocations stealing
> from Movable pageblocks, the allocations will spread over larger areas
> instead of being grouped together. Maybe, for Movable allocations
> stealing from Unmovable allocations, preferring smallest might make
> sense and be safe, as any extra fragmentation is fixable bycompaction.
> Maybe it was already tried (by Joonsoo?) at some point, I'm not sure
> right now.
>
>> My test is against arm64 android devices with kernel 3.10.49. I set the
>> same account and install the same applications in both deivces and use
>> them synchronously.
>
> 3.10 is wayyyyyy old. There were numerous patches to compaction and
> anti-fragmentation since then. IIRC the fallback decisions were quite
> suboptimal at that point. I'm not even sure how you could apply your
> patches to both recent kernel for posting them, and 3.10 for testing?
> Is it possible to test on 4.4?
>
I think it's hard to update the drivers on android smart phone.
Thanks,
Xishi Qiu
>>
>> Test result:
>> 1) Test without this patch:
>> Most free pages are order-0 Unmovable ones. allocstall and compact_stall
>> in /proc/vmstat are relatively high. And most occurances of allocstall
>> are due to order-2 and order-3 allocations.
>> 2) Test with this patch:
>> There are more order-2 and order-3 free pages. allocstall and
>> compact_stall in /proc/vmstat are relatively low. And most occurances of
>> allocstall are due to order-0 allocations.
>>
>> Log:
>> 1) Test without this patch:
>> ------ TIME (date) ------
>> Fri Jul 3 16:52:55 CST 2015
>> ------ UPTIME (uptime) ------
>> up time: 2 days, 12:06:52, idle time: 8 days, 14:48:55, sleep time: 16:43:56
>> ------ MEMORY INFO (/proc/meminfo) ------
>> MemTotal: 2792568 kB
>> MemFree: 194524 kB
>> Buffers: 3788 kB
>> Cached: 380872 kB
>> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
>> Free pages count per migrate type at order 0 1 2 3 4
>> Node 0, zone DMA, type Unmovable 43852 701 0 0 0
>> Node 0, zone DMA, type Reclaimable 3357 0 0 0 0
>> Node 0, zone DMA, type Movable 0 5 0 0 0
>> Node 0, zone DMA, type Reserve 0 1 5 0 0
>> Node 0, zone DMA, type CMA 2 0 0 0 0
>> Node 0, zone DMA, type Isolate 0 0 0 0 0
>> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
>> Node 0, zone DMA 362 80 170 2 113 0
>> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
>> pgsteal_kswapd_dma 31755040
>> pgsteal_direct_dma 34597394
>> pgscan_kswapd_dma 36427664
>> pgscan_direct_dma 39490711
>> kswapd_low_wmark_hit_quickly 201929
>> kswapd_high_wmark_hit_quickly 4858
>> allocstall 664269
>> allocstall_order_0 9738
>> allocstall_order_1 1787
>> allocstall_order_2 637608
>> allocstall_order_3 15136
>> pgmigrate_success 2941956
>> pgmigrate_fail 1033
>> compact_migrate_scanned 142985157
>> compact_free_scanned 4734040109
>> compact_isolated 7720362
>> compact_stall 65978
>> compact_fail 46084
>> compact_success 11717
>>
>> 2) Test with this patch:
>> ------ TIME (date) ------
>> Fri Jul 3 16:52:31 CST 2015
>> ------ UPTIME (uptime) ------
>> up time: 2 days, 12:06:30
>> ------ MEMORY INFO (/proc/meminfo) ------
>> MemTotal: 2792568 kB
>> MemFree: 47612 kB
>> Buffers: 3732 kB
>> Cached: 387048 kB
>> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
>> Free pages count per migrate type at order 0 1 2 3 4
>> Node 0, zone DMA, type Unmovable 272 243 126 1 0
>> Node 0, zone DMA, type Reclaimable 0 361 168 46 0
>> Node 0, zone DMA, type Movable 4103 1782 130 3 0
>> Node 0, zone DMA, type Reserve 0 0 0 0 0
>> Node 0, zone DMA, type CMA 563 2 0 0 0
>> Node 0, zone DMA, type Isolate 0 0 0 0 0
>> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
>> Node 0, zone DMA 183 12 417 2 113 0
>> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
>> pgsteal_kswapd_dma 50710868
>> pgsteal_direct_dma 1756780
>> pgscan_kswapd_dma 58281837
>> pgscan_direct_dma 2022049
>> kswapd_low_wmark_hit_quickly 37599
>> kswapd_high_wmark_hit_quickly 13564
>> allocstall 27510
>> allocstall_order_0 26101
>> allocstall_order_1 23
>> allocstall_order_2 1224
>> allocstall_order_3 162
>> pgmigrate_success 63751
>> pgmigrate_fail 7
>> compact_migrate_scanned 278170
>> compact_free_scanned 6155410
>> compact_isolated 140762
>> compact_stall 749
>> compact_fail 54
>> compact_success 22
>> unevictable_pgs_culled 794
>>
>> Below is the status of another device with this patch.
>> /proc/pagetypeinfo shows that even if there are no Movable pages, there
>> are lots of order-2 and order-3 Unmovable pages. For this case, if the
>> patch is not applied, then order-2 and order-3 Unmovable pages will be
>> split easily. It's likely that system perforamnce will become low due to
>> severe external fragmentation.
>>
>> ------ UPTIME (uptime) ------
>> up time: 33 days, 08:10:58
>> ------ MEMORY INFO (/proc/meminfo) ------
>> MemTotal: 2792568 kB
>> MemFree: 37340 kB
>> Buffers: 13412 kB
>> Cached: 655456 kB
>> ------ PAGETYPEINFO (/proc/pagetypeinfo) ------
>> Free pages count per migrate type at order 0 1 2 3 4
>> Node 0, zone DMA, type Unmovable 718 628 1116 301 0
>> Node 0, zone DMA, type Reclaimable 198 93 0 0 0
>> Node 0, zone DMA, type Movable 0 0 0 0 0
>> Node 0, zone DMA, type Reserve 0 0 0 0 0
>> Node 0, zone DMA, type CMA 89 11 3 0 0
>> Node 0, zone DMA, type Isolate 0 0 0 0 0
>> Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate
>> Node 0, zone DMA 377 115 120 2 113 0
>> ------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
>> pgsteal_direct_dma 28575192
>> pgsteal_kswapd_dma 378357910
>> pgscan_kswapd_dma 422765699
>> pgscan_direct_dma 31860747
>> kswapd_low_wmark_hit_quickly 947979
>> kswapd_high_wmark_hit_quickly 139901
>> allocstall 592989
>> compact_migrate_scanned 149884903
>> compact_free_scanned 6629299888
>> compact_isolated 7699012
>> compact_stall 52550
>> compact_fail 45155
>> compact_success 6057
>>
>> ChengYi He (2):
>> mm/page_alloc: let migration fallback support pages of requested order
>> mm/page_alloc: avoid splitting pages of order 2 and 3 in migration
>> fallback
>>
>> mm/page_alloc.c | 92 ++++++++++++++++++++++++++++++++++++---------------------
>> 1 file changed, 59 insertions(+), 33 deletions(-)
>>
>
>
> .
>
--
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] 16+ messages in thread
* Re: [RFC PATCH 2/2] mm/page_alloc: avoid splitting pages of order 2 and 3 in migration fallback
2016-01-29 19:25 ` ChengYi He
@ 2016-01-30 10:41 ` Xishi Qiu
-1 siblings, 0 replies; 16+ messages in thread
From: Xishi Qiu @ 2016-01-30 10:41 UTC (permalink / raw)
To: ChengYi He
Cc: Andrew Morton, Mel Gorman, Michal Hocko, Vlastimil Babka,
David Rientjes, Joonsoo Kim, Yaowei Bai, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On 2016/1/30 3:25, ChengYi He wrote:
> While buddy system fallbacks to allocate different migration type pages,
> it prefers the largest feasible pages and might split the chosen page
> into smalller ones. If the largest feasible pages are less than or equal
> to orde-3 and migration fallback happens frequently, then order-2 and
> order-3 pages can be exhausted easily. This patch aims to allocate the
> smallest feasible pages for the fallback mechanism under this condition.
>
> Signed-off-by: ChengYi He <chengyihetaipei@gmail.com>
> ---
> mm/page_alloc.c | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 50c325a..3fcb653 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1802,9 +1802,22 @@ __rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
> struct page *page;
>
> /* Find the largest possible block of pages in the other list */
> - for (current_order = MAX_ORDER-1;
> - current_order >= order && current_order <= MAX_ORDER-1;
> - --current_order) {
> + for (current_order = MAX_ORDER - 1;
> + current_order >= max_t(unsigned int, PAGE_ALLOC_COSTLY_ORDER + 1, order);
> + --current_order) {
> + page = __rmqueue_fallback_order(zone, order, start_migratetype,
> + current_order);
> +
> + if (page)
> + return page;
> + }
> +
> + /*
> + * While current_order <= PAGE_ALLOC_COSTLY_ORDER, find the smallest
> + * feasible pages in the other list to avoid splitting high order pages
> + */
> + for (current_order = order; current_order <= PAGE_ALLOC_COSTLY_ORDER;
> + ++current_order) {
> page = __rmqueue_fallback_order(zone, order, start_migratetype,
> current_order);
>
Hi Chengyi,
So you mean use the largest block first, if no large block left, the use the
smallest block, right?
I have an idea, how about set two migrate types(movable and unmovable) when
doing init work? The function is memmap_init_zone().
I don't know how to set the ratio, maybe unmovable takes 1/10 memory, and left
9/10 memory to movable? I think this effect is a little like the two zones
(normal and movable).
Another two ideas
https://lkml.org/lkml/2015/8/14/67
7d348b9ea64db0a315d777ce7d4b06697f946503, maybe this patch is not applied on your 3.10
Thanks,
Xishi Qiu
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 2/2] mm/page_alloc: avoid splitting pages of order 2 and 3 in migration fallback
@ 2016-01-30 10:41 ` Xishi Qiu
0 siblings, 0 replies; 16+ messages in thread
From: Xishi Qiu @ 2016-01-30 10:41 UTC (permalink / raw)
To: ChengYi He
Cc: Andrew Morton, Mel Gorman, Michal Hocko, Vlastimil Babka,
David Rientjes, Joonsoo Kim, Yaowei Bai, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On 2016/1/30 3:25, ChengYi He wrote:
> While buddy system fallbacks to allocate different migration type pages,
> it prefers the largest feasible pages and might split the chosen page
> into smalller ones. If the largest feasible pages are less than or equal
> to orde-3 and migration fallback happens frequently, then order-2 and
> order-3 pages can be exhausted easily. This patch aims to allocate the
> smallest feasible pages for the fallback mechanism under this condition.
>
> Signed-off-by: ChengYi He <chengyihetaipei@gmail.com>
> ---
> mm/page_alloc.c | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 50c325a..3fcb653 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1802,9 +1802,22 @@ __rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
> struct page *page;
>
> /* Find the largest possible block of pages in the other list */
> - for (current_order = MAX_ORDER-1;
> - current_order >= order && current_order <= MAX_ORDER-1;
> - --current_order) {
> + for (current_order = MAX_ORDER - 1;
> + current_order >= max_t(unsigned int, PAGE_ALLOC_COSTLY_ORDER + 1, order);
> + --current_order) {
> + page = __rmqueue_fallback_order(zone, order, start_migratetype,
> + current_order);
> +
> + if (page)
> + return page;
> + }
> +
> + /*
> + * While current_order <= PAGE_ALLOC_COSTLY_ORDER, find the smallest
> + * feasible pages in the other list to avoid splitting high order pages
> + */
> + for (current_order = order; current_order <= PAGE_ALLOC_COSTLY_ORDER;
> + ++current_order) {
> page = __rmqueue_fallback_order(zone, order, start_migratetype,
> current_order);
>
Hi Chengyi,
So you mean use the largest block first, if no large block left, the use the
smallest block, right?
I have an idea, how about set two migrate types(movable and unmovable) when
doing init work? The function is memmap_init_zone().
I don't know how to set the ratio, maybe unmovable takes 1/10 memory, and left
9/10 memory to movable? I think this effect is a little like the two zones
(normal and movable).
Another two ideas
https://lkml.org/lkml/2015/8/14/67
7d348b9ea64db0a315d777ce7d4b06697f946503, maybe this patch is not applied on your 3.10
Thanks,
Xishi Qiu
--
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] 16+ messages in thread
* Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
2016-01-29 21:03 ` Vlastimil Babka
@ 2016-02-01 13:53 ` Mel Gorman
-1 siblings, 0 replies; 16+ messages in thread
From: Mel Gorman @ 2016-02-01 13:53 UTC (permalink / raw)
To: Vlastimil Babka
Cc: ChengYi He, Andrew Morton, Michal Hocko, David Rientjes,
Joonsoo Kim, Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On Fri, Jan 29, 2016 at 10:03:52PM +0100, Vlastimil Babka wrote:
> > Since the root cause is that fallbacks might frequently split order-2
> > and order-3 pages of the other migration types. This patch tweaks
> > fallback mechanism to avoid splitting order-2 and order-3 pages. while
> > fallbacks happen, if the largest feasible pages are less than or queal to
> > COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
> > reason why fallbacks prefer the largest feasiable pages is to increase
> > fallback efficiency since fallbacks are likely to happen again. By
> > stealing the largest feasible pages, it could reduce the oppourtunities
> > of antoher fallback. Besides, it could make consecutive allocations more
> > approximate to each other and make system less fragment. However, if the
> > largest feasible pages are less than or equal to order-3, fallbacks might
> > split it and make the upcoming order-3 page allocations fail.
>
> In theory I don't see immediately why preferring smaller pages for
> fallback should be a clear win. If it's Unmovable allocations stealing
> from Movable pageblocks, the allocations will spread over larger areas
> instead of being grouped together. Maybe, for Movable allocations
> stealing from Unmovable allocations, preferring smallest might make
> sense and be safe, as any extra fragmentation is fixable bycompaction.
I strongly agree that spreading the fallback allocations over a larger
area is likely to have a negative impact. Given the age of the kernel
being tested, it would make sense to either rebase or at the very last
backport the patches that affect watermark calculations and the
treatment of high-order pages.
--
Mel Gorman
SUSE Labs
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
@ 2016-02-01 13:53 ` Mel Gorman
0 siblings, 0 replies; 16+ messages in thread
From: Mel Gorman @ 2016-02-01 13:53 UTC (permalink / raw)
To: Vlastimil Babka
Cc: ChengYi He, Andrew Morton, Michal Hocko, David Rientjes,
Joonsoo Kim, Yaowei Bai, Xishi Qiu, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On Fri, Jan 29, 2016 at 10:03:52PM +0100, Vlastimil Babka wrote:
> > Since the root cause is that fallbacks might frequently split order-2
> > and order-3 pages of the other migration types. This patch tweaks
> > fallback mechanism to avoid splitting order-2 and order-3 pages. while
> > fallbacks happen, if the largest feasible pages are less than or queal to
> > COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
> > reason why fallbacks prefer the largest feasiable pages is to increase
> > fallback efficiency since fallbacks are likely to happen again. By
> > stealing the largest feasible pages, it could reduce the oppourtunities
> > of antoher fallback. Besides, it could make consecutive allocations more
> > approximate to each other and make system less fragment. However, if the
> > largest feasible pages are less than or equal to order-3, fallbacks might
> > split it and make the upcoming order-3 page allocations fail.
>
> In theory I don't see immediately why preferring smaller pages for
> fallback should be a clear win. If it's Unmovable allocations stealing
> from Movable pageblocks, the allocations will spread over larger areas
> instead of being grouped together. Maybe, for Movable allocations
> stealing from Unmovable allocations, preferring smallest might make
> sense and be safe, as any extra fragmentation is fixable bycompaction.
I strongly agree that spreading the fallback allocations over a larger
area is likely to have a negative impact. Given the age of the kernel
being tested, it would make sense to either rebase or at the very last
backport the patches that affect watermark calculations and the
treatment of high-order pages.
--
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] 16+ messages in thread
* Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
2016-02-01 13:53 ` Mel Gorman
@ 2016-02-02 1:01 ` Xishi Qiu
-1 siblings, 0 replies; 16+ messages in thread
From: Xishi Qiu @ 2016-02-02 1:01 UTC (permalink / raw)
To: Mel Gorman
Cc: Vlastimil Babka, ChengYi He, Andrew Morton, Michal Hocko,
David Rientjes, Joonsoo Kim, Yaowei Bai, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On 2016/2/1 21:53, Mel Gorman wrote:
> On Fri, Jan 29, 2016 at 10:03:52PM +0100, Vlastimil Babka wrote:
>>> Since the root cause is that fallbacks might frequently split order-2
>>> and order-3 pages of the other migration types. This patch tweaks
>>> fallback mechanism to avoid splitting order-2 and order-3 pages. while
>>> fallbacks happen, if the largest feasible pages are less than or queal to
>>> COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
>>> reason why fallbacks prefer the largest feasiable pages is to increase
>>> fallback efficiency since fallbacks are likely to happen again. By
>>> stealing the largest feasible pages, it could reduce the oppourtunities
>>> of antoher fallback. Besides, it could make consecutive allocations more
>>> approximate to each other and make system less fragment. However, if the
>>> largest feasible pages are less than or equal to order-3, fallbacks might
>>> split it and make the upcoming order-3 page allocations fail.
>>
>> In theory I don't see immediately why preferring smaller pages for
>> fallback should be a clear win. If it's Unmovable allocations stealing
>> from Movable pageblocks, the allocations will spread over larger areas
>> instead of being grouped together. Maybe, for Movable allocations
>> stealing from Unmovable allocations, preferring smallest might make
>> sense and be safe, as any extra fragmentation is fixable bycompaction.
>
> I strongly agree that spreading the fallback allocations over a larger
> area is likely to have a negative impact. Given the age of the kernel
> being tested, it would make sense to either rebase or at the very last
> backport the patches that affect watermark calculations and the
> treatment of high-order pages.
>
Is it the feature of MIGRATE_HIGHATOMIC?
Thanks,
Xishi Qiu
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback
@ 2016-02-02 1:01 ` Xishi Qiu
0 siblings, 0 replies; 16+ messages in thread
From: Xishi Qiu @ 2016-02-02 1:01 UTC (permalink / raw)
To: Mel Gorman
Cc: Vlastimil Babka, ChengYi He, Andrew Morton, Michal Hocko,
David Rientjes, Joonsoo Kim, Yaowei Bai, Alexander Duyck,
'Kirill A . Shutemov',
Johannes Weiner, linux-mm, linux-kernel
On 2016/2/1 21:53, Mel Gorman wrote:
> On Fri, Jan 29, 2016 at 10:03:52PM +0100, Vlastimil Babka wrote:
>>> Since the root cause is that fallbacks might frequently split order-2
>>> and order-3 pages of the other migration types. This patch tweaks
>>> fallback mechanism to avoid splitting order-2 and order-3 pages. while
>>> fallbacks happen, if the largest feasible pages are less than or queal to
>>> COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
>>> reason why fallbacks prefer the largest feasiable pages is to increase
>>> fallback efficiency since fallbacks are likely to happen again. By
>>> stealing the largest feasible pages, it could reduce the oppourtunities
>>> of antoher fallback. Besides, it could make consecutive allocations more
>>> approximate to each other and make system less fragment. However, if the
>>> largest feasible pages are less than or equal to order-3, fallbacks might
>>> split it and make the upcoming order-3 page allocations fail.
>>
>> In theory I don't see immediately why preferring smaller pages for
>> fallback should be a clear win. If it's Unmovable allocations stealing
>> from Movable pageblocks, the allocations will spread over larger areas
>> instead of being grouped together. Maybe, for Movable allocations
>> stealing from Unmovable allocations, preferring smallest might make
>> sense and be safe, as any extra fragmentation is fixable bycompaction.
>
> I strongly agree that spreading the fallback allocations over a larger
> area is likely to have a negative impact. Given the age of the kernel
> being tested, it would make sense to either rebase or at the very last
> backport the patches that affect watermark calculations and the
> treatment of high-order pages.
>
Is it the feature of MIGRATE_HIGHATOMIC?
Thanks,
Xishi Qiu
--
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] 16+ messages in thread
end of thread, other threads:[~2016-02-02 1:06 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-29 19:23 [RFC PATCH 0/2] avoid external fragmentation related to migration fallback ChengYi He
2016-01-29 19:23 ` ChengYi He
2016-01-29 19:24 ` [RFC PATCH 1/2] mm/page_alloc: let migration fallback support pages of requested order ChengYi He
2016-01-29 19:24 ` ChengYi He
2016-01-29 19:25 ` [RFC PATCH 2/2] mm/page_alloc: avoid splitting pages of order 2 and 3 in migration fallback ChengYi He
2016-01-29 19:25 ` ChengYi He
2016-01-30 10:41 ` Xishi Qiu
2016-01-30 10:41 ` Xishi Qiu
2016-01-29 21:03 ` [RFC PATCH 0/2] avoid external fragmentation related to " Vlastimil Babka
2016-01-29 21:03 ` Vlastimil Babka
2016-01-30 10:21 ` Xishi Qiu
2016-01-30 10:21 ` Xishi Qiu
2016-02-01 13:53 ` Mel Gorman
2016-02-01 13:53 ` Mel Gorman
2016-02-02 1:01 ` Xishi Qiu
2016-02-02 1:01 ` Xishi Qiu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.