Re: [patch] ipv4: don't warn about skb ack allocation failures
From: David Rientjes
Date: Thu Jun 18 2009 - 15:23:44 EST
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/