mm: Do not boost watermarks to avoid fragmentation for the DISCONTIG memory model
Subsystems (6)
PATCH 1/1 mm: Do not boost watermarks to avoid fragmentation for the DISCONTIG memory model
Mikulas Patocka reported that 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 MBFrom his own report
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.
--- Documentation/sysctl/vm.txt | 16 ++++++++-------- mm/page_alloc.c | 13 +++++++++++++ 2 files changed, 21 insertions(+), 8 deletions(-)
Documentation/sysctl/vm.txt +8 -8
@@ -866,14 +866,14 @@ The intent is that compaction has less work to do in the future and to increase the success rate of future high-order allocations such as SLUB allocations, THP and hugetlbfs pages. -To make it sensible with respect to the watermark_scale_factor parameter, -the unit is in fractions of 10,000. The default value of 15,000 means -that up to 150% of the high watermark will be reclaimed in the event of -a pageblock being mixed due to fragmentation. The level of reclaim is -determined by the number of fragmentation events that occurred in the -recent past. If this value is smaller than a pageblock then a pageblocks -worth of pages will be reclaimed (e.g. 2MB on 64-bit x86). A boost factor -of 0 will disable the feature. +To make it sensible with respect to the watermark_scale_factor +parameter, the unit is in fractions of 10,000. The default value of +15,000 on !DISCONTIGMEM configurations means that up to 150% of the high +watermark will be reclaimed in the event of a pageblock being mixed due +to fragmentation. The level of reclaim is determined by the number of +fragmentation events that occurred in the recent past. If this value is +smaller than a pageblock then a pageblocks worth of pages will be reclaimed +(e.g. 2MB on 64-bit x86). A boost factor of 0 will disable the feature. =============================================================
mm/page_alloc.c +13 -0
@@ -266,7 +266,20 @@ compound_page_dtor * const compound_page_dtors[] = {int min_free_kbytes =1024 ;int user_min_free_kbytes =-1 ; +#ifdef CONFIG_DISCONTIGMEM +/* +* DiscontigMem defines memory ranges as separate pg_data_t even if the ranges +* are not on separate NUMA nodes. Functionally this works but with +* watermark_boost_factor, it can reclaim prematurely as the ranges can be +* quite small. By default, do not boost watermarks on discontigmem as in +* many cases very high-order allocations like THP are likely to be +* unsupported and the premature reclaim offsets the advantage of long-term +* fragmentation avoidance. +*/ +int watermark_boost_factor__read_mostly ; +#else int watermark_boost_factor__read_mostly =15000 ; +#endif int watermark_scale_factor =10 ;static unsigned long nr_kernel_pages__initdata ;
DISCONTIGMEM is deprecated
Quoted 3 lines · Mel Gorman
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.
I don't think parisc is the only arch which uses DISCONTIGMEM for !NUMA scenarios. Grepping the arch/ directories shows:
alpha (does support NUMA, but also non-NUMA DISCONTIGMEM) arc (for supporting more than 1GB of memory) ia64 (looks complicated ...)
m68k (for multiple chunks of memory)
mips (does support NUMA but also non-NUMA) parisc (both NUMA and non-NUMA)
I'm not sure that these architecture maintainers even know that DISCONTIGMEM is deprecated. Adding linux-arch to the cc.
Re: DISCONTIGMEM is deprecated
Quoted 15 lines · Matthew Wilcox
Quoted 3 lines · Mel Gorman
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.
I don't think parisc is the only arch which uses DISCONTIGMEM for !NUMA scenarios. Grepping the
arch/directories shows:alpha (does support NUMA, but also non-NUMA DISCONTIGMEM) arc (for supporting more than 1GB of memory) ia64 (looks complicated ...)
m68k (for multiple chunks of memory)
mips (does support NUMA but also non-NUMA) parisc (both NUMA and non-NUMA)
Quoted 2 lines
I'm not sure that these architecture maintainers even know that DISCONTIGMEM is deprecated. Adding linux-arch to the cc.
Poor wording then -- yes, DISCONTIGMEM is still used but look where it's used. I find it impossible to believe that any new arch would support DISCONTIGMEM or that DISCONTIGMEM would be selected when SPARSEMEM is available.`It's even more insane when you consider that SPARSEMEM can be extended to support VMEMMAP so that it has similar overhead to FLATMEM when mapping pfns to struct pages and vice-versa.
Signature · 2 lines
Mel Gorman SUSE Labs
Helge Deller
maintainerRe: DISCONTIGMEM is deprecated
Quoted 19 lines · Mel Gorman
Quoted 15 lines · Matthew Wilcox
Quoted 3 lines · Mel Gorman
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.
I don't think parisc is the only arch which uses DISCONTIGMEM for !NUMA scenarios. Grepping the
arch/directories shows:alpha (does support NUMA, but also non-NUMA DISCONTIGMEM) arc (for supporting more than 1GB of memory) ia64 (looks complicated ...)
m68k (for multiple chunks of memory)
mips (does support NUMA but also non-NUMA) parisc (both NUMA and non-NUMA)Quoted 2 lines
I'm not sure that these architecture maintainers even know that DISCONTIGMEM is deprecated. Adding linux-arch to the cc.
Quoted 6 lines
Poor wording then -- yes, DISCONTIGMEM is still used but look where it's used. I find it impossible to believe that any new arch would support DISCONTIGMEM or that DISCONTIGMEM would be selected when SPARSEMEM is available.`It's even more insane when you consider that SPARSEMEM can be extended to support VMEMMAP so that it has similar overhead to FLATMEM when mapping pfns to struct pages and vice-versa.
FYI, on parisc we will switch from DISCONTIGMEM to SPARSEMEM with kernel 5.2. The patch was quite simple and it's currently in the for-next tree:
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next&id=281b718721a5e78288271d632731cea9697749f7
Helge
Re: DISCONTIGMEM is deprecated
Hi,
Quoted 27 lines · Helge Deller
Quoted 19 lines · Mel Gorman
Quoted 15 lines · Matthew Wilcox
Quoted 3 lines · Mel Gorman
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.
I don't think parisc is the only arch which uses DISCONTIGMEM for !NUMA scenarios. Grepping the
arch/directories shows:alpha (does support NUMA, but also non-NUMA DISCONTIGMEM) arc (for supporting more than 1GB of memory) ia64 (looks complicated ...)
m68k (for multiple chunks of memory)
mips (does support NUMA but also non-NUMA) parisc (both NUMA and non-NUMA)Quoted 2 lines
I'm not sure that these architecture maintainers even know that DISCONTIGMEM is deprecated. Adding linux-arch to the cc.
Quoted 6 lines
Poor wording then -- yes, DISCONTIGMEM is still used but look where it's used. I find it impossible to believe that any new arch would support DISCONTIGMEM or that DISCONTIGMEM would be selected when SPARSEMEM is available.`It's even more insane when you consider that SPARSEMEM can be extended to support VMEMMAP so that it has similar overhead to FLATMEM when mapping pfns to struct pages and vice-versa.
Quoted 3 lines
FYI, on parisc we will switch from DISCONTIGMEM to SPARSEMEM with kernel 5.2. The patch was quite simple and it's currently in the for-next tree:
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next&id=281b718721a5e78288271d632731cea9697749f7
A while ago I've sent a patch that removes ARCH_DISCARD_MEMBLOCK option [1] so the hunk below is not needed:
arch/parisc/Kconfig +1 -0
@@ -36,6 +36,7 @@ config PARISC select GENERIC_STRNCPY_FROM_USER select SYSCTL_ARCH_UNALIGN_ALLOW select SYSCTL_EXCEPTION_TRACE + select ARCH_DISCARD_MEMBLOCK select HAVE_MOD_ARCH_SPECIFIC select VIRT_TO_BUS select MODULES_USE_ELF_RELA
[1] https://lore.kernel.org/lkml/[email protected]/
Quoted 2 lines
Helge
Signature · 2 lines
Sincerely yours, Mike.
Re: DISCONTIGMEM is deprecated
In reply to Matthew WilcoxQuoted 8 lines · Matthew Wilcox
Quoted 3 lines · Mel Gorman
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.
I don't think parisc is the only arch which uses DISCONTIGMEM for !NUMA scenarios. Grepping the
arch/directories shows:
Quoted 6 lines
alpha (does support NUMA, but also non-NUMA DISCONTIGMEM) arc (for supporting more than 1GB of memory) ia64 (looks complicated ...)
m68k (for multiple chunks of memory)
mips (does support NUMA but also non-NUMA) parisc (both NUMA and non-NUMA)
i386 NUMA as well
Quoted 3 lines
I'm not sure that these architecture maintainers even know that DISCONTIGMEM is deprecated. Adding linux-arch to the cc.
Signature · 2 lines
Sincerely yours, Mike.
Re: DISCONTIGMEM is deprecated
Quoted 9 lines · Mike Rapoport
Quoted 8 lines · Matthew Wilcox
Quoted 3 lines · Mel Gorman
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.
I don't think parisc is the only arch which uses DISCONTIGMEM for !NUMA scenarios. Grepping the
arch/directories shows:
Quoted 8 lines
Quoted 6 lines
alpha (does support NUMA, but also non-NUMA DISCONTIGMEM) arc (for supporting more than 1GB of memory) ia64 (looks complicated ...)
m68k (for multiple chunks of memory)
mips (does support NUMA but also non-NUMA) parisc (both NUMA and non-NUMA)i386 NUMA as well
I clearly over-trimmed. The original assumption that Mel had was that DISCONTIGMEM => NUMA, and that's not true on the above six architectures. It is true on i386 ;-)
Re: DISCONTIGMEM is deprecated
Quoted 17 lines · Matthew Wilcox
Quoted 16 lines · Mike Rapoport
Quoted 14 lines · Matthew Wilcox
Quoted 3 lines · Mel Gorman
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.
I don't think parisc is the only arch which uses DISCONTIGMEM for !NUMA scenarios. Grepping the
arch/directories shows:alpha (does support NUMA, but also non-NUMA DISCONTIGMEM) arc (for supporting more than 1GB of memory) ia64 (looks complicated ...)
m68k (for multiple chunks of memory)
mips (does support NUMA but also non-NUMA) parisc (both NUMA and non-NUMA)
Quoted 5 lines
Quoted 1 line
i386 NUMA as well
I clearly over-trimmed. The original assumption that Mel had was that DISCONTIGMEM => NUMA, and that's not true on the above six architectures. It is true on i386 ;-)
32-bit NUMA systems should be non-existent in practice. The last NUMA system I'm aware of that was both NUMA and 32-bit only died somewhere between 2004 and 2007. If someone is running a 64-bit capable system in 32-bit mode with NUMA, they really are just punishing themselves for fun.
Signature · 2 lines
Mel Gorman SUSE Labs
Re: DISCONTIGMEM is deprecated
Quoted 4 lines · Mel Gorman
32-bit NUMA systems should be non-existent in practice. The last NUMA system I'm aware of that was both NUMA and 32-bit only died somewhere between 2004 and 2007. If someone is running a 64-bit capable system in 32-bit mode with NUMA, they really are just punishing themselves for fun.
Can we mark it as BROKEN to see if someone shouts and then remove it a year or two down the road? Or just kill it off now..
Re: DISCONTIGMEM is deprecated
Quoted 8 lines · Christoph Hellwig
Quoted 4 lines · Mel Gorman
32-bit NUMA systems should be non-existent in practice. The last NUMA system I'm aware of that was both NUMA and 32-bit only died somewhere between 2004 and 2007. If someone is running a 64-bit capable system in 32-bit mode with NUMA, they really are just punishing themselves for fun.
Can we mark it as BROKEN to see if someone shouts and then remove it a year or two down the road? Or just kill it off now..
How about making SPARSEMEM default for x86-32?
From ac2dc27414e26f799ea063fd1d01e19d70056f43 Mon Sep 17 00:00:00 2001
From: Mike Rapoport <[email protected]>
Date: Wed, 24 Apr 2019 14:32:12 +0300
Subject: [PATCH] x86/Kconfig: make SPARSEMEM default for X86_32
--- arch/x86/Kconfig | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
arch/x86/Kconfig +1 -5
@@ -1609,10 +1609,6 @@ config ARCH_DISCONTIGMEM_ENABLE def_bool y depends on NUMA && X86_32 -config ARCH_DISCONTIGMEM_DEFAULT - def_bool y - depends on NUMA && X86_32 - config ARCH_SPARSEMEM_ENABLE def_bool y depends on X86_64 || NUMA || X86_32 || X86_32_NON_STANDARD
@@ -1621,7 +1617,7 @@ config ARCH_SPARSEMEM_ENABLE config ARCH_SPARSEMEM_DEFAULT def_bool y - depends on X86_64 + depends on X86_64 || (NUMA && X86_32) config ARCH_SELECT_MEMORY_MODEL def_bool y
Signature · 6 lines
2.7.4 -- Sincerely yours, Mike.
Re: DISCONTIGMEM is deprecated
Quoted 7 lines · Mike Rapoport
Quoted 6 lines · Christoph Hellwig
Quoted 4 lines · Mel Gorman
32-bit NUMA systems should be non-existent in practice. The last NUMA system I'm aware of that was both NUMA and 32-bit only died somewhere between 2004 and 2007. If someone is running a 64-bit capable system in 32-bit mode with NUMA, they really are just punishing themselves for fun.
Quoted 5 lines
Quoted 2 lines
Can we mark it as BROKEN to see if someone shouts and then remove it a year or two down the road? Or just kill it off now..
How about making SPARSEMEM default for x86-32?
While an improvement, I tend to agree with Christoph that marking it BROKEN as a patch on top of this makes sense and wait to see who, if anyone, screams. If it's quiet for long enough then we can remove it entirely.
Signature · 2 lines
Mel Gorman SUSE Labs
Re: DISCONTIGMEM is deprecated
In reply to Mike RapoportQuoted 11 lines · Mike Rapoport
Quoted 8 lines · Christoph Hellwig
Quoted 4 lines · Mel Gorman
32-bit NUMA systems should be non-existent in practice. The last NUMA system I'm aware of that was both NUMA and 32-bit only died somewhere between 2004 and 2007. If someone is running a 64-bit capable system in 32-bit mode with NUMA, they really are just punishing themselves for fun.
Can we mark it as BROKEN to see if someone shouts and then remove it a year or two down the road? Or just kill it off now..
How about making SPARSEMEM default for x86-32?
Sounds good.
Another question: I always found the option to even select the memory models like a bad tradeoff. Can we really expect a user to make a sane choice? I'd rather stick to a relativelty optimal choice based on arch and maybe a few other parameters (NUMA or not for example) and stick to it, reducing the testing matrix.
Re: DISCONTIGMEM is deprecated
Quoted 13 lines · Christoph Hellwig
Quoted 11 lines · Mike Rapoport
Quoted 8 lines · Christoph Hellwig
Quoted 4 lines · Mel Gorman
32-bit NUMA systems should be non-existent in practice. The last NUMA system I'm aware of that was both NUMA and 32-bit only died somewhere between 2004 and 2007. If someone is running a 64-bit capable system in 32-bit mode with NUMA, they really are just punishing themselves for fun.
Can we mark it as BROKEN to see if someone shouts and then remove it a year or two down the road? Or just kill it off now..
How about making SPARSEMEM default for x86-32?
Quoted 7 lines
Sounds good.
Another question: I always found the option to even select the memory models like a bad tradeoff. Can we really expect a user to make a sane choice? I'd rather stick to a relativelty optimal choice based on arch and maybe a few other parameters (NUMA or not for example) and stick to it, reducing the testing matrix.
I've sent patches that remove ARCH_SELECT_MEMORY_MODEL from arm, s390 and sparc where it anyway has no effect [1].
That leaves arm64, ia64, parisc, powerpc, sh and i386.
I'd say that for i386 selecting between FLAT and SPARSE based on NUMA sounds reasonable.
I'm not familiar enough with others to say if such enforcement makes any sense.
Probably powerpc and sh can enable the preferred memory model in platform/board part of their Kconfig, just like arm.
[1] https://lore.kernel.org/lkml/[email protected]
Signature · 2 lines
Sincerely yours, Mike.
Re: DISCONTIGMEM is deprecated
In reply to Matthew WilcoxQuoted 1 line · Matthew Wilcox
ia64 (looks complicated ...)
Well as far as I can tell it was not even used 12 or so years ago on Itanium when I worked on that stuff.
Re: DISCONTIGMEM is deprecated
Quoted 4 lines
Quoted 1 line
ia64 (looks complicated ...)
Well as far as I can tell it was not even used 12 or so years ago on Itanium when I worked on that stuff.
My notes tell that on UP ia64 (RX2620), !NUMA was broken with both SPARSEMEM and DISCONTIGMEM. NUMA+SPARSEMEM or !NUMA worked. Even NUMA+DISCONTIGMEM worked, that was my config on 2-CPU RX2660.
Signature · 1 line
Meelis Roos
Re: DISCONTIGMEM is deprecated
Quoted 8 lines · Meelis Roos
Quoted 4 lines
Quoted 1 line
ia64 (looks complicated ...)
Well as far as I can tell it was not even used 12 or so years ago on Itanium when I worked on that stuff.
My notes tell that on UP ia64 (RX2620), !NUMA was broken with both SPARSEMEM and DISCONTIGMEM. NUMA+SPARSEMEM or !NUMA worked. Even NUMA+DISCONTIGMEM worked, that was my config on 2-CPU RX2660.
ia64 has a such a huge number of memory model choices. Maybe we need to cut it down to a small set that actually work.
That includes fund bits like the 'VIRTUAL_MEM_MAP' option where the comment claims:
# VIRTUAL_MEM_MAP and FLAT_NODE_MEM_MAP are functionally equivalent. # VIRTUAL_MEM_MAP has been retained for historical reasons.
but it still is selected as the default if sparsemem is not enabled..
RE: DISCONTIGMEM is deprecated
Quoted 2 lines
ia64 has a such a huge number of memory model choices. Maybe we need to cut it down to a small set that actually work.
SGI systems had extremely discontiguous memory (they used some high order physical address bits in the tens/hundreds of terabyte range for the node number ... so there would be a few GBytes of actual memory then a huge gap before the next node had a few more Gbytes).
I don't know of anyone still booting upstream on an SN2, so if we start doing serious hack and slash the chances are high that SN2 will be broken (if it isn't already).
-Tony
Re: DISCONTIGMEM is deprecated
Quoted 11 lines · Tony
Quoted 2 lines
ia64 has a such a huge number of memory model choices. Maybe we need to cut it down to a small set that actually work.
SGI systems had extremely discontiguous memory (they used some high order physical address bits in the tens/hundreds of terabyte range for the node number ... so there would be a few GBytes of actual memory then a huge gap before the next node had a few more Gbytes).
I don't know of anyone still booting upstream on an SN2, so if we start doing serious hack and slash the chances are high that SN2 will be broken (if it isn't already).
When I wrote this, I thought of
!NUMA: flat mem
NUMA: sparsemem
SN2: discontig
based on Meelis report. But now that you mention it, I bet SN2 has already died slow death from bitrot. It is so different in places, and it doesn't seem like anyone care - if people want room sized SGI machines the Origin is much more sexy (hello Thomas!) :)
So maybe it it time to mark SN2 broken and see if anyone screams?
Without SN2 the whole machvec mess could basically go away - the only real difference between the remaining machvecs is which iommu if any we set up.
Re: DISCONTIGMEM is deprecated
Quoted 5 lines · Christoph Hellwig
So maybe it it time to mark SN2 broken and see if anyone screams?
Without SN2 the whole machvec mess could basically go away - the only real difference between the remaining machvecs is which iommu if any we set up.
SPARSEMEM with VMEMMAP was developed to address these issues and allow one mapping scheme across the different platforms.
You do not need DISCONTIGMEM support for SN2. And as far as I know (from a decade ago ok....) the distributions were using VMEMMAP instead.
Quoted 29 lines · Mel Gorman
Mikulas Patocka reported that
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 ranges0) Start 0x0000000000000000 End 0x000000003fffffff Size 1024 MB 1) Start 0x0000000100000000 End 0x00000001bfdfffff Size 3070 MB 2) Start 0x0000004040000000 End 0x00000040ffffffff Size 3072 MBFrom his own report
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.
Quoted 8 lines
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.
Fixes 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs")Reported-by Mikulas Patocka <[email protected]>Tested-by Mikulas Patocka <[email protected]>Signed-off-by Mel Gorman <[email protected]>
Quoted 58 lines
--- Documentation/sysctl/vm.txt | 16 ++++++++-------- mm/page_alloc.c | 13 +++++++++++++ 2 files changed, 21 insertions(+), 8 deletions(-)Documentation/sysctl/vm.txt +8
-8@@ -866,14 +866,14 @@ The intent is that compaction has less work to do in the future and to increase the success rate of future high-order allocations such as SLUB allocations, THP and hugetlbfs pages. -To make it sensible with respect to the watermark_scale_factor parameter, -the unit is in fractions of 10,000. The default value of 15,000 means -that up to 150% of the high watermark will be reclaimed in the event of -a pageblock being mixed due to fragmentation. The level of reclaim is -determined by the number of fragmentation events that occurred in the -recent past. If this value is smaller than a pageblock then a pageblocks -worth of pages will be reclaimed (e.g. 2MB on 64-bit x86). A boost factor -of 0 will disable the feature. +To make it sensible with respect to the watermark_scale_factor +parameter, the unit is in fractions of 10,000. The default value of +15,000 on !DISCONTIGMEM configurations means that up to 150% of the high +watermark will be reclaimed in the event of a pageblock being mixed due +to fragmentation. The level of reclaim is determined by the number of +fragmentation events that occurred in the recent past. If this value is +smaller than a pageblock then a pageblocks worth of pages will be reclaimed +(e.g. 2MB on 64-bit x86). A boost factor of 0 will disable the feature. =============================================================mm/page_alloc.c +13
-0@@ -266,7 +266,20 @@ compound_page_dtor * const compound_page_dtors[] = {int min_free_kbytes =1024 ;int user_min_free_kbytes =-1 ; +#ifdef CONFIG_DISCONTIGMEM +/* +* DiscontigMem defines memory ranges as separate pg_data_t even if the ranges +* are not on separate NUMA nodes. Functionally this works but with +* watermark_boost_factor, it can reclaim prematurely as the ranges can be +* quite small. By default, do not boost watermarks on discontigmem as in +* many cases very high-order allocations like THP are likely to be +* unsupported and the premature reclaim offsets the advantage of long-term +* fragmentation avoidance. +*/ +int watermark_boost_factor__read_mostly ; +#else int watermark_boost_factor__read_mostly =15000 ; +#endif int watermark_scale_factor =10 ;static unsigned long nr_kernel_pages__initdata ;