Re: [PATCH] mm, page_alloc: Remove debug_guardpage_minorder() test in warn_alloc().

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Stanislaw Gruszka wrote:
> On Tue, Apr 11, 2017 at 08:27:15PM +0900, Tetsuo Handa wrote:
> > Commit c0a32fc5a2e470d0 ("mm: more intensive memory corruption debugging")
> > changed to check debug_guardpage_minorder() > 0 when reporting allocation
> > failures. But the patch description seems to lack why we want to check it.
> 
> When we use guard page to debug memory corruption, it shrinks available
> pages to 1/2, 1/4, 1/8 and so on, depending on parameter value.
> In such case memory allocation failures can be common and printing
> errors can flood dmesg. If sombody debug corruption, allocation
> failures are not the things he/she is interested about.

Nowadays we likely have a lot of memory where shrinking available pages to
1/2, 1/4, 1/8 and so on would not cause flooding of allocation failure messages.
Thus, I hope removing debug_guardpage_minorder() > 0 test affects only systems
with small memory. But

> 
> > Let's remove that check so that administrators can get some clue by
> > allowing warn_alloc() to report e.g. GFP_NOFS | __GFP_NOWARN allocations
> > are stalling.
> 
> This is ok for me, but perhaps move debug_guardpage_minorder() > 0
> check before calling warn_alloc() in buddy allocator when it fails,
> or move it before __ratelimit(), will be better option.

before proposing this patch, I proposed a patch at
http://lkml.kernel.org/r/1491825493-8859-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
that ignores debug_guardpage_minorder() > 0 only when reporting allocation stalls.
We can preserve debug_guardpage_minorder() > 0 test if we change to use
a different function for reporting allocation stalls.

Which patch do you prefer?

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