[PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures

[PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures

[Michal Hocko]

From: Michal Hocko <mhocko@suse.com>

While doing a memory hotplug tests under a heavy memory pressure we have
noticed too many page allocation failures when allocating vmemmap memmap
backed by huge page
[146792.281354] kworker/u3072:1: page allocation failure: order:9, mode:0x24084c0(GFP_KERNEL|__GFP_REPEAT|__GFP_ZERO)
[...]
[146792.281394] Call Trace:
[146792.281430]  [<ffffffff81019a99>] dump_trace+0x59/0x310
[146792.281436]  [<ffffffff81019e3a>] show_stack_log_lvl+0xea/0x170
[146792.281440]  [<ffffffff8101abc1>] show_stack+0x21/0x40
[146792.281448]  [<ffffffff8130f040>] dump_stack+0x5c/0x7c
[146792.281464]  [<ffffffff8118c982>] warn_alloc_failed+0xe2/0x150
[146792.281471]  [<ffffffff8118cddd>] __alloc_pages_nodemask+0x3ed/0xb20
[146792.281489]  [<ffffffff811d3aaf>] alloc_pages_current+0x7f/0x100
[146792.281503]  [<ffffffff815dfa2c>] vmemmap_alloc_block+0x79/0xb6
[146792.281510]  [<ffffffff815dfbd3>] __vmemmap_alloc_block_buf+0x136/0x145
[146792.281524]  [<ffffffff815dd0c5>] vmemmap_populate+0xd2/0x2b9
[146792.281529]  [<ffffffff815dffd9>] sparse_mem_map_populate+0x23/0x30
[146792.281532]  [<ffffffff815df88d>] sparse_add_one_section+0x68/0x18e
[146792.281537]  [<ffffffff815d9f5a>] __add_pages+0x10a/0x1d0
[146792.281553]  [<ffffffff8106249a>] arch_add_memory+0x4a/0xc0
[146792.281559]  [<ffffffff815da1f9>] add_memory_resource+0x89/0x160
[146792.281564]  [<ffffffff815da33d>] add_memory+0x6d/0xd0
[146792.281585]  [<ffffffff813d36c4>] acpi_memory_device_add+0x181/0x251
[146792.281597]  [<ffffffff813946e5>] acpi_bus_attach+0xfd/0x19b
[146792.281602]  [<ffffffff81394866>] acpi_bus_scan+0x59/0x69
[146792.281604]  [<ffffffff813949de>] acpi_device_hotplug+0xd2/0x41f
[146792.281608]  [<ffffffff8138db67>] acpi_hotplug_work_fn+0x1a/0x23
[146792.281623]  [<ffffffff81093cee>] process_one_work+0x14e/0x410
[146792.281630]  [<ffffffff81094546>] worker_thread+0x116/0x490
[146792.281637]  [<ffffffff810999ed>] kthread+0xbd/0xe0
[146792.281651]  [<ffffffff815e4e7f>] ret_from_fork+0x3f/0x70

and we do see many of those because essentially every the allocation
failes for each memory section. This is overly excessive way to tell
user that there is nothing to really worry about because we do have
a fallback mechanism to use base pages. The only downside might be a
performance degradation due to TLB pressure.

This patch changes vmemmap_alloc_block to use __GFP_NOWARN and warn
explicitly once on the first allocation failure. This will reduce the
noise in the kernel log considerably, while we still have an indication
that a performance might be impacted.

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
Hi,
this has somehow fell of my radar completely. The patch is essentially
what Johannes suggested [1] so I have added his s-o-b and added the
changelog into it.

Can we have this merged?

[1] http://lkml.kernel.org/r/20170711214541.GA11141@cmpxchg.org

 arch/x86/mm/init_64.c |  1 -
 mm/sparse-vmemmap.c   | 11 +++++++++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 126e09625979..5eb954f930be 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1405,7 +1405,6 @@ static int __meminit vmemmap_populate_hugepages(unsigned long start,
 			vmemmap_verify((pte_t *)pmd, node, addr, next);
 			continue;
 		}
-		pr_warn_once("vmemmap: falling back to regular page backing\n");
 		if (vmemmap_populate_basepages(addr, next, node))
 			return -ENOMEM;
 	}
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index d0860aab1c89..3f85084cb8bb 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -52,12 +52,19 @@ void * __meminit vmemmap_alloc_block(unsigned long size, int node)
 {
 	/* If the main allocator is up use that, fallback to bootmem. */
 	if (slab_is_available()) {
+		gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
+		int order = get_order(size);
+		static bool warned;
 		struct page *page;
 
-		page = alloc_pages_node(node, GFP_KERNEL | __GFP_RETRY_MAYFAIL,
-					get_order(size));
+		page = alloc_pages_node(node, gfp_mask, order);
 		if (page)
 			return page_address(page);
+
+		if (!warned) {
+			warn_alloc(gfp_mask, NULL, "vmemmap alloc failure: order:%u", order);
+			warned = true;
+		}
 		return NULL;
 	} else
 		return __earlyonly_bootmem_alloc(node, size, size,
-- 
2.14.2

--
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>

Re: [PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures

[Johannes Weiner]

On Mon, Nov 06, 2017 at 10:22:28AM +0100, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> While doing a memory hotplug tests under a heavy memory pressure we have
> noticed too many page allocation failures when allocating vmemmap memmap
> backed by huge page
> [146792.281354] kworker/u3072:1: page allocation failure: order:9, mode:0x24084c0(GFP_KERNEL|__GFP_REPEAT|__GFP_ZERO)
> [...]
> [146792.281394] Call Trace:
> [146792.281430]  [<ffffffff81019a99>] dump_trace+0x59/0x310
> [146792.281436]  [<ffffffff81019e3a>] show_stack_log_lvl+0xea/0x170
> [146792.281440]  [<ffffffff8101abc1>] show_stack+0x21/0x40
> [146792.281448]  [<ffffffff8130f040>] dump_stack+0x5c/0x7c
> [146792.281464]  [<ffffffff8118c982>] warn_alloc_failed+0xe2/0x150
> [146792.281471]  [<ffffffff8118cddd>] __alloc_pages_nodemask+0x3ed/0xb20
> [146792.281489]  [<ffffffff811d3aaf>] alloc_pages_current+0x7f/0x100
> [146792.281503]  [<ffffffff815dfa2c>] vmemmap_alloc_block+0x79/0xb6
> [146792.281510]  [<ffffffff815dfbd3>] __vmemmap_alloc_block_buf+0x136/0x145
> [146792.281524]  [<ffffffff815dd0c5>] vmemmap_populate+0xd2/0x2b9
> [146792.281529]  [<ffffffff815dffd9>] sparse_mem_map_populate+0x23/0x30
> [146792.281532]  [<ffffffff815df88d>] sparse_add_one_section+0x68/0x18e
> [146792.281537]  [<ffffffff815d9f5a>] __add_pages+0x10a/0x1d0
> [146792.281553]  [<ffffffff8106249a>] arch_add_memory+0x4a/0xc0
> [146792.281559]  [<ffffffff815da1f9>] add_memory_resource+0x89/0x160
> [146792.281564]  [<ffffffff815da33d>] add_memory+0x6d/0xd0
> [146792.281585]  [<ffffffff813d36c4>] acpi_memory_device_add+0x181/0x251
> [146792.281597]  [<ffffffff813946e5>] acpi_bus_attach+0xfd/0x19b
> [146792.281602]  [<ffffffff81394866>] acpi_bus_scan+0x59/0x69
> [146792.281604]  [<ffffffff813949de>] acpi_device_hotplug+0xd2/0x41f
> [146792.281608]  [<ffffffff8138db67>] acpi_hotplug_work_fn+0x1a/0x23
> [146792.281623]  [<ffffffff81093cee>] process_one_work+0x14e/0x410
> [146792.281630]  [<ffffffff81094546>] worker_thread+0x116/0x490
> [146792.281637]  [<ffffffff810999ed>] kthread+0xbd/0xe0
> [146792.281651]  [<ffffffff815e4e7f>] ret_from_fork+0x3f/0x70
> 
> and we do see many of those because essentially every the allocation
> failes for each memory section. This is overly excessive way to tell
> user that there is nothing to really worry about because we do have
> a fallback mechanism to use base pages. The only downside might be a
> performance degradation due to TLB pressure.
> 
> This patch changes vmemmap_alloc_block to use __GFP_NOWARN and warn
> explicitly once on the first allocation failure. This will reduce the
> noise in the kernel log considerably, while we still have an indication
> that a performance might be impacted.
> 
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> Hi,
> this has somehow fell of my radar completely. The patch is essentially
> what Johannes suggested [1] so I have added his s-o-b and added the
> changelog into it.

Looks good to me.

--
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>

Re: [PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures

[Joe Perches]

[-- Attachment #1: Type: text/plain, Size: 3867 bytes --]

On Mon, 2017-11-06 at 12:35 -0500, Johannes Weiner wrote:
> On Mon, Nov 06, 2017 at 10:22:28AM +0100, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.com>
> > 
> > While doing a memory hotplug tests under a heavy memory pressure we have
> > noticed too many page allocation failures when allocating vmemmap memmap
> > backed by huge page
> > [146792.281354] kworker/u3072:1: page allocation failure: order:9, mode:0x24084c0(GFP_KERNEL|__GFP_REPEAT|__GFP_ZERO)
> > [...]
> > [146792.281394] Call Trace:
> > [146792.281430]  [<ffffffff81019a99>] dump_trace+0x59/0x310
> > [146792.281436]  [<ffffffff81019e3a>] show_stack_log_lvl+0xea/0x170
> > [146792.281440]  [<ffffffff8101abc1>] show_stack+0x21/0x40
> > [146792.281448]  [<ffffffff8130f040>] dump_stack+0x5c/0x7c
> > [146792.281464]  [<ffffffff8118c982>] warn_alloc_failed+0xe2/0x150
> > [146792.281471]  [<ffffffff8118cddd>] __alloc_pages_nodemask+0x3ed/0xb20
> > [146792.281489]  [<ffffffff811d3aaf>] alloc_pages_current+0x7f/0x100
> > [146792.281503]  [<ffffffff815dfa2c>] vmemmap_alloc_block+0x79/0xb6
> > [146792.281510]  [<ffffffff815dfbd3>] __vmemmap_alloc_block_buf+0x136/0x145
> > [146792.281524]  [<ffffffff815dd0c5>] vmemmap_populate+0xd2/0x2b9
> > [146792.281529]  [<ffffffff815dffd9>] sparse_mem_map_populate+0x23/0x30
> > [146792.281532]  [<ffffffff815df88d>] sparse_add_one_section+0x68/0x18e
> > [146792.281537]  [<ffffffff815d9f5a>] __add_pages+0x10a/0x1d0
> > [146792.281553]  [<ffffffff8106249a>] arch_add_memory+0x4a/0xc0
> > [146792.281559]  [<ffffffff815da1f9>] add_memory_resource+0x89/0x160
> > [146792.281564]  [<ffffffff815da33d>] add_memory+0x6d/0xd0
> > [146792.281585]  [<ffffffff813d36c4>] acpi_memory_device_add+0x181/0x251
> > [146792.281597]  [<ffffffff813946e5>] acpi_bus_attach+0xfd/0x19b
> > [146792.281602]  [<ffffffff81394866>] acpi_bus_scan+0x59/0x69
> > [146792.281604]  [<ffffffff813949de>] acpi_device_hotplug+0xd2/0x41f
> > [146792.281608]  [<ffffffff8138db67>] acpi_hotplug_work_fn+0x1a/0x23
> > [146792.281623]  [<ffffffff81093cee>] process_one_work+0x14e/0x410
> > [146792.281630]  [<ffffffff81094546>] worker_thread+0x116/0x490
> > [146792.281637]  [<ffffffff810999ed>] kthread+0xbd/0xe0
> > [146792.281651]  [<ffffffff815e4e7f>] ret_from_fork+0x3f/0x70
> > 
> > and we do see many of those because essentially every the allocation
> > failes for each memory section. This is overly excessive way to tell
> > user that there is nothing to really worry about because we do have
> > a fallback mechanism to use base pages. The only downside might be a
> > performance degradation due to TLB pressure.
> > 
> > This patch changes vmemmap_alloc_block to use __GFP_NOWARN and warn
> > explicitly once on the first allocation failure. This will reduce the
> > noise in the kernel log considerably, while we still have an indication
> > that a performance might be impacted.
> > 
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
> > ---
> > Hi,
> > this has somehow fell of my radar completely. The patch is essentially
> > what Johannes suggested [1] so I have added his s-o-b and added the
> > changelog into it.
> 
> Looks good to me.

I think it'd be better to change the ratelimit state
to something like once a minute
---
 mm/page_alloc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 82e6d2c914ab..af3f92beec04 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3269,8 +3269,7 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...)
 {
 	struct va_format vaf;
 	va_list args;
-	static DEFINE_RATELIMIT_STATE(nopage_rs, DEFAULT_RATELIMIT_INTERVAL,
-				      DEFAULT_RATELIMIT_BURST);
+	static DEFINE_RATELIMIT_STATE(nopage_rs, HZ * 60, 1);
 
 	if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(&nopage_rs))
 		return;

[-- Attachment #2: 1.difd --]
[-- Type: text/plain, Size: 584 bytes --]

 mm/page_alloc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 82e6d2c914ab..af3f92beec04 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3269,8 +3269,7 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...)
 {
 	struct va_format vaf;
 	va_list args;
-	static DEFINE_RATELIMIT_STATE(nopage_rs, DEFAULT_RATELIMIT_INTERVAL,
-				      DEFAULT_RATELIMIT_BURST);
+	static DEFINE_RATELIMIT_STATE(nopage_rs, HZ * 60, 1);
 
 	if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(&nopage_rs))
 		return;

Re: [PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures

[Khalid Aziz]

On Mon, 2017-11-06 at 10:22 +0100, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> While doing a memory hotplug tests under a heavy memory pressure we
> have
> noticed too many page allocation failures when allocating vmemmap
> memmap
> backed by huge page
> ......... deleted .........
> +
> +		if (!warned) {
> +			warn_alloc(gfp_mask, NULL, "vmemmap alloc
> failure: order:%u", order);
> +			warned = true;
> +		}
>  		return NULL;
>  	} else
>  		return __earlyonly_bootmem_alloc(node, size, size,

This will warn once and only once after a kernel is booted. This
condition may happen repeatedly over a long period of time with
significant time span between two such events and it can be useful to
know if this is happening repeatedly. There might be better ways to
throttle the rate of warnings, something like warn once and then
suppress warnings for the next 15 minutes (or pick any other time
frame). If this condition happens again later, there will be another
warning.

--
Khalid

--
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>

Re: [PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures

[Michal Hocko]

On Mon 06-11-17 11:14:27, Khalid Aziz wrote:
> On Mon, 2017-11-06 at 10:22 +0100, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.com>
> > 
> > While doing a memory hotplug tests under a heavy memory pressure we
> > have
> > noticed too many page allocation failures when allocating vmemmap
> > memmap
> > backed by huge page
> > ......... deleted .........
> > +
> > +		if (!warned) {
> > +			warn_alloc(gfp_mask, NULL, "vmemmap alloc
> > failure: order:%u", order);
> > +			warned = true;
> > +		}
> >  		return NULL;
> >  	} else
> >  		return __earlyonly_bootmem_alloc(node, size, size,
> 
> This will warn once and only once after a kernel is booted. This
> condition may happen repeatedly over a long period of time with
> significant time span between two such events and it can be useful to
> know if this is happening repeatedly. There might be better ways to
> throttle the rate of warnings, something like warn once and then
> suppress warnings for the next 15 minutes (or pick any other time
> frame). If this condition happens again later, there will be another
> warning.

While this is all true I am not sure we care all that much. The failure
mode is basically not using an optimization. This is not something we
warn normally about. Even the performance degradation is a theoretical
concern which nobody has backed by real life numbers AFAIR.

If we want to make it more sophisticated I would expect some numbers to
back such a change.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures

[Khalid Aziz]

On 11/06/2017 11:18 AM, Michal Hocko wrote:
> If we want to make it more sophisticated I would expect some numbers to
> back such a change.
> 

That is reasonable enough.

--
Khalid

--
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>

Re: [RFC PATCH for 4.15 10/14] cpu_opv: Wire up powerpc system call

[Nicholas Piggin]

On Mon,  6 Nov 2017 15:56:40 -0500
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> diff --git a/arch/powerpc/include/uapi/asm/unistd.h b/arch/powerpc/include/uapi/asm/unistd.h
> index b1980fcd56d5..972a7d68c143 100644
> --- a/arch/powerpc/include/uapi/asm/unistd.h
> +++ b/arch/powerpc/include/uapi/asm/unistd.h
> @@ -396,5 +396,6 @@
>  #define __NR_kexec_file_load	382
>  #define __NR_statx		383
>  #define __NR_rseq		384
> +#define __NR_cpu_opv		385

Sorry for bike shedding, but could we invest a few more keystrokes to
make these names a bit more readable?

Thanks,
Nick

--
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>

Re: [RFC PATCH for 4.15 10/14] cpu_opv: Wire up powerpc system call

[Mathieu Desnoyers]

----- On Nov 6, 2017, at 7:37 PM, Nicholas Piggin npiggin@gmail.com wrote:

> On Mon,  6 Nov 2017 15:56:40 -0500
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
>> diff --git a/arch/powerpc/include/uapi/asm/unistd.h
>> b/arch/powerpc/include/uapi/asm/unistd.h
>> index b1980fcd56d5..972a7d68c143 100644
>> --- a/arch/powerpc/include/uapi/asm/unistd.h
>> +++ b/arch/powerpc/include/uapi/asm/unistd.h
>> @@ -396,5 +396,6 @@
>>  #define __NR_kexec_file_load	382
>>  #define __NR_statx		383
>>  #define __NR_rseq		384
>> +#define __NR_cpu_opv		385
> 
> Sorry for bike shedding, but could we invest a few more keystrokes to
> make these names a bit more readable?

Whenever I try to make variables or function names more explicit, I can
literally feel my consciousness (taking the form of an angry Peter Zijlstra)
breathing down my neck asking me to make them shorter. So I guess this is
where it becomes a question of taste.

I think the "rseq" syscall name is short, to the point, and should be mostly
fine.

For "cpu_opv", it was just a short name that fit the bill until a
better idea would come.

I'm open to suggestions. Any color preference ? ;-)

Thanks,

Mathieu


> 
> Thanks,
> Nick

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

--
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>

Re: [RFC PATCH for 4.15 10/14] cpu_opv: Wire up powerpc system call

[Nicholas Piggin]

On Tue, 7 Nov 2017 00:47:17 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> ----- On Nov 6, 2017, at 7:37 PM, Nicholas Piggin npiggin@gmail.com wrote:
> 
> > On Mon,  6 Nov 2017 15:56:40 -0500
> > Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> >   
> >> diff --git a/arch/powerpc/include/uapi/asm/unistd.h
> >> b/arch/powerpc/include/uapi/asm/unistd.h
> >> index b1980fcd56d5..972a7d68c143 100644
> >> --- a/arch/powerpc/include/uapi/asm/unistd.h
> >> +++ b/arch/powerpc/include/uapi/asm/unistd.h
> >> @@ -396,5 +396,6 @@
> >>  #define __NR_kexec_file_load	382
> >>  #define __NR_statx		383
> >>  #define __NR_rseq		384
> >> +#define __NR_cpu_opv		385  
> > 
> > Sorry for bike shedding, but could we invest a few more keystrokes to
> > make these names a bit more readable?  
> 
> Whenever I try to make variables or function names more explicit, I can
> literally feel my consciousness (taking the form of an angry Peter Zijlstra)
> breathing down my neck asking me to make them shorter. So I guess this is
> where it becomes a question of taste.

Specialist syscall is a bit different than a common function or variable
though.

> 
> I think the "rseq" syscall name is short, to the point, and should be mostly
> fine.

I'm not sure if it's really "to the point". I think kexec_file_load
is better than kfload, for example :)

> For "cpu_opv", it was just a short name that fit the bill until a
> better idea would come.
> 
> I'm open to suggestions. Any color preference ? ;-)

What can you do within 16 characters?

--
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>

Re: [PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures

[Michal Hocko]

Dohh, forgot to git add the follow up fix on top of Johannes' original
diff so it didn't make it into the finall commit. Could you fold this
into the patch Andrew, please?

Sorry about that.
---
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 3f85084cb8bb..9a745e2a6f9a 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -62,7 +62,7 @@ void * __meminit vmemmap_alloc_block(unsigned long size, int node)
 			return page_address(page);
 
 		if (!warned) {
-			warn_alloc(gfp_mask, NULL, "vmemmap alloc failure: order:%u", order);
+			warn_alloc(gfp_mask & ~__GFP_NOWARN, NULL, "vmemmap alloc failure: order:%u", order);
 			warned = true;
 		}
 		return NULL;
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>