From: David Rientjes <rientjes@google.com>
To: David Miller <davem@davemloft.net>
Cc: eric.dumazet@gmail.com, jpiszcz@lucidpixels.com,
linux-kernel@vger.kernel.org
Subject: Re: [patch] ipv4: don't warn about skb ack allocation failures
Date: Thu, 18 Jun 2009 12:23:28 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.00.0906181212380.10979@chino.kir.corp.google.com> (raw)
In-Reply-To: <20090618.120034.246557840.davem@davemloft.net>
On Thu, 18 Jun 2009, David Miller wrote:
> > I disagree, page allocation failure messages show vital information about
> > the state of the VM so that we can find bugs and GFP_ATOMIC allocations
> > are the most common trigger for these diagnostic messages since
> > __GFP_WAIT allocations can trigger direct reclaim (and __GFP_FS
> > allocations can trigger the oom killer) to free memory and will retry the
> > allocation if ~__GFP_NORETRY.
>
> It's COMPLETELY and ABSOLUTELY normal for GFP_ATOMIC allocations to
> fail in the networking.
>
__GFP_NOWARN exists for that reason.
> If you warn it will just spam the logs, and on a router forwarding
> millions of packets per second are you sure that can ever be sane?
>
The spamming is ratelimited, but GFP_ATOMIC is really the only time we get
such diagnostic information since __GFP_WAIT allocations can reclaim,
__GFP_FS allocations can utilize the oom killer, and other order-0
allocations are implicitly ~__GFP_NORETRY.
As previously mentioned, GFP_ATOMIC allocations that are not __GFP_NOWARN
have been emitting these diagnostics since 2.5.53. This has been on your
TODO list for 6 1/2 years and now you insist all GFP_ATOMIC allocations
change their default behavior?
I understand what you're trying to avoid, but I disagree with the approach
of altering the default behavior of GFP_ATOMIC. I may suggest that
emitting the page allocation failures become a compile time option;
CONFIG_DEBUG_VM would be my suggestion.
> Use statistics and tracing if necessary, but log spam no way...
>
You need the meminfo that is emitted at the time of failure for it to be
useful.
next prev parent reply other threads:[~2009-06-18 19:23 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.DEB.2.00.0906161203160.27742@p34.internal.lan>
2009-06-16 16:06 ` 2.6.29.1: nfsd: page allocation failure - nfsd or kernel problem? Justin Piszcz
2009-06-16 20:19 ` Michael Tokarev
2009-06-17 8:43 ` Michael Tokarev
2009-06-17 9:43 ` Justin Piszcz
2009-06-17 10:39 ` Michael Tokarev
2009-06-17 18:51 ` J. Bruce Fields
2009-06-17 20:24 ` Michael Tokarev
2009-06-17 20:39 ` David Rientjes
2009-06-18 8:54 ` Michael Tokarev
2009-06-18 17:07 ` David Rientjes
2009-06-18 17:56 ` Michael Tokarev
2009-06-18 18:12 ` J. Bruce Fields
2009-06-18 18:15 ` David Rientjes
2009-06-17 22:45 ` J. Bruce Fields
2009-06-18 0:14 ` Zdenek Kaspar
2009-06-17 19:44 ` [patch] ipv4: don't warn about skb ack allocation failures David Rientjes
2009-06-17 20:16 ` Eric Dumazet
2009-06-17 20:33 ` David Rientjes
2009-06-17 20:52 ` Eric Dumazet
2009-06-17 21:12 ` David Rientjes
2009-06-17 22:30 ` Eric Dumazet
2009-06-17 23:08 ` David Miller
2009-06-18 16:56 ` David Rientjes
2009-06-18 19:00 ` David Miller
2009-06-18 19:23 ` David Rientjes [this message]
2009-06-18 19:37 ` David Miller
2009-06-19 19:45 ` David Rientjes
2009-06-19 20:41 ` Eric W. Biederman
2009-06-19 22:37 ` David Rientjes
2009-06-19 23:04 ` David Miller
2009-06-20 1:28 ` Eric W. Biederman
2009-06-19 23:03 ` David Miller
2009-06-22 16:08 ` 2.6.30: nfsd: page allocation failure - nfsd or kernel problem? (again with 2.6.30) Justin Piszcz
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=alpine.DEB.2.00.0906181212380.10979@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
/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.