aboutsummaryrefslogtreecommitdiffstats
path: root/mm/page_alloc.c
diff options
context:
space:
mode:
authorMel Gorman <mgorman@techsingularity.net>2019-04-26 01:23:51 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2019-04-26 12:18:05 -0400
commit24512228b7a3f412b5a51f189df302616b021c33 (patch)
tree983d0e8ea8ebc889bf36b79e2a70ce2c74c13e1e /mm/page_alloc.c
parente789803507b2e154ed452865ee981b038654e98d (diff)
mm: do not boost watermarks to avoid fragmentation for the DISCONTIG memory model
Mikulas Patocka reported that commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs") "broke" memory management on parisc. The machine is not NUMA but the DISCONTIG model creates three pgdats even though it's a UMA machine for the following ranges 0) Start 0x0000000000000000 End 0x000000003fffffff Size 1024 MB 1) Start 0x0000000100000000 End 0x00000001bfdfffff Size 3070 MB 2) Start 0x0000004040000000 End 0x00000040ffffffff Size 3072 MB Mikulas reported: With the patch 1c30844d2, the kernel will incorrectly reclaim the first zone when it fills up, ignoring the fact that there are two completely free zones. Basiscally, it limits cache size to 1GiB. For example, if I run: # dd if=/dev/sda of=/dev/null bs=1M count=2048 - with the proper kernel, there should be "Buffers - 2GiB" when this command finishes. With the patch 1c30844d2, buffers will consume just 1GiB or slightly more, because the kernel was incorrectly reclaiming them. The page allocator and reclaim makes assumptions that pgdats really represent NUMA nodes and zones represent ranges and makes decisions on that basis. Watermark boosting for small pgdats leads to unexpected results even though this would have behaved reasonably on SPARSEMEM. DISCONTIG is essentially deprecated and even parisc plans to move to SPARSEMEM so there is no need to be fancy, this patch simply disables watermark boosting by default on DISCONTIGMEM. Link: http://lkml.kernel.org/r/20190419094335.GJ18914@techsingularity.net Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs") Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Reported-by: Mikulas Patocka <mpatocka@redhat.com> Tested-by: Mikulas Patocka <mpatocka@redhat.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: James Bottomley <James.Bottomley@hansenpartnership.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/page_alloc.c')
-rw-r--r--mm/page_alloc.c13
1 files changed, 13 insertions, 0 deletions
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c6ce20aaf80b..6c6d9f1c404e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -266,7 +266,20 @@ compound_page_dtor * const compound_page_dtors[] = {
266 266
267int min_free_kbytes = 1024; 267int min_free_kbytes = 1024;
268int user_min_free_kbytes = -1; 268int user_min_free_kbytes = -1;
269#ifdef CONFIG_DISCONTIGMEM
270/*
271 * DiscontigMem defines memory ranges as separate pg_data_t even if the ranges
272 * are not on separate NUMA nodes. Functionally this works but with
273 * watermark_boost_factor, it can reclaim prematurely as the ranges can be
274 * quite small. By default, do not boost watermarks on discontigmem as in
275 * many cases very high-order allocations like THP are likely to be
276 * unsupported and the premature reclaim offsets the advantage of long-term
277 * fragmentation avoidance.
278 */
279int watermark_boost_factor __read_mostly;
280#else
269int watermark_boost_factor __read_mostly = 15000; 281int watermark_boost_factor __read_mostly = 15000;
282#endif
270int watermark_scale_factor = 10; 283int watermark_scale_factor = 10;
271 284
272static unsigned long nr_kernel_pages __initdata; 285static unsigned long nr_kernel_pages __initdata;