From: Andrew Morton <akpm@linux-foundation.org>
To: Rik van Riel <riel@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH] mm: do not print backtraces on GFP_ATOMIC failures
Date: Tue, 21 Sep 2010 09:46:38 -0700 [thread overview]
Message-ID: <20100921094638.9910add0.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100921121818.4745f038@annuminas.surriel.com>
On Tue, 21 Sep 2010 12:18:18 -0400 Rik van Riel <riel@redhat.com> wrote:
> Atomic allocations cannot fall back to the page eviction code
> and are expected to fail. In fact, in some network intensive
> workloads, it is common to experience hundreds of GFP_ATOMIC
> allocation failures.
>
> Printing out a backtrace for every one of those expected
> allocation failures accomplishes nothing good. At multi-gigabit
> network speeds with jumbo frames, a burst of allocation failure
> backtraces could even slow down the system.
>
> We're better off not printing out backtraces on GFP_ATOMIC
> allocation failures.
>
> Signed-off-by: Rik van Riel <riel@redhat.com>
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 975609c..5a0bddb 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -72,7 +72,7 @@ struct vm_area_struct;
> /* This equals 0, but use constants in case they ever change */
> #define GFP_NOWAIT (GFP_ATOMIC & ~__GFP_HIGH)
> /* GFP_ATOMIC means both !wait (__GFP_WAIT not set) and use emergency pool */
> -#define GFP_ATOMIC (__GFP_HIGH)
> +#define GFP_ATOMIC (__GFP_HIGH | __GFP_NOWARN)
> #define GFP_NOIO (__GFP_WAIT)
> #define GFP_NOFS (__GFP_WAIT | __GFP_IO)
> #define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
A much finer-tuned implementation would be to add __GFP_NOWARN just to
the networking call sites. I asked about this in June and it got
nixed:
http://www.spinics.net/lists/netdev/msg131965.html
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Rik van Riel <riel@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH] mm: do not print backtraces on GFP_ATOMIC failures
Date: Tue, 21 Sep 2010 09:46:38 -0700 [thread overview]
Message-ID: <20100921094638.9910add0.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100921121818.4745f038@annuminas.surriel.com>
On Tue, 21 Sep 2010 12:18:18 -0400 Rik van Riel <riel@redhat.com> wrote:
> Atomic allocations cannot fall back to the page eviction code
> and are expected to fail. In fact, in some network intensive
> workloads, it is common to experience hundreds of GFP_ATOMIC
> allocation failures.
>
> Printing out a backtrace for every one of those expected
> allocation failures accomplishes nothing good. At multi-gigabit
> network speeds with jumbo frames, a burst of allocation failure
> backtraces could even slow down the system.
>
> We're better off not printing out backtraces on GFP_ATOMIC
> allocation failures.
>
> Signed-off-by: Rik van Riel <riel@redhat.com>
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 975609c..5a0bddb 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -72,7 +72,7 @@ struct vm_area_struct;
> /* This equals 0, but use constants in case they ever change */
> #define GFP_NOWAIT (GFP_ATOMIC & ~__GFP_HIGH)
> /* GFP_ATOMIC means both !wait (__GFP_WAIT not set) and use emergency pool */
> -#define GFP_ATOMIC (__GFP_HIGH)
> +#define GFP_ATOMIC (__GFP_HIGH | __GFP_NOWARN)
> #define GFP_NOIO (__GFP_WAIT)
> #define GFP_NOFS (__GFP_WAIT | __GFP_IO)
> #define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
A much finer-tuned implementation would be to add __GFP_NOWARN just to
the networking call sites. I asked about this in June and it got
nixed:
http://www.spinics.net/lists/netdev/msg131965.html
--
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>
next prev parent reply other threads:[~2010-09-21 16:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-21 16:18 [PATCH] mm: do not print backtraces on GFP_ATOMIC failures Rik van Riel
2010-09-21 16:18 ` Rik van Riel
2010-09-21 16:46 ` Andrew Morton [this message]
2010-09-21 16:46 ` Andrew Morton
2010-09-21 17:00 ` Eric Dumazet
2010-09-21 17:00 ` Eric Dumazet
2010-09-21 17:00 ` Eric Dumazet
2010-09-27 2:17 ` KOSAKI Motohiro
2010-09-27 2:17 ` KOSAKI Motohiro
2010-09-27 18:49 ` Andrew Morton
2010-09-27 18:49 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100921094638.9910add0.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.