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@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
