Re: [patch] ipv4: don't warn about skb ack allocation failures

From: David Rientjes
Date: Thu Jun 18 2009 - 12:56:31 EST

On Wed, 17 Jun 2009, David Miller wrote:

> From: Eric Dumazet <eric.dumazet@xxxxxxxxx>
> Date: Thu, 18 Jun 2009 00:30:58 +0200
> > My point is that 99% of callers know allocation failures are
> > recoverable.
> I agree that, surely for GFP_ATOMIC, warnings should be off
> by default.

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.

GFP_ATOMIC allocations are allowed to access memory deeper in zone
watermarks so that they are more likely to succeed; page allocation
failure messages indicate that the system is either completely oom or that
there is a serious VM bug.

Defining GFP_ATOMIC as (__GFP_HIGH | __GFP_NOWARN) would also require the
bit to be masked off if page allocation failure messages should be
emitted. GFP_ATOMIC | GFP_DMA allocations become
(GFP_ATOMIC | GFP_DMA) & ~__GFP_NOWARN, for example. This is not normally
how GFP_* macros are composed from __GFP_* bits because of the increasing

It's again my opinion that allocators that can recover ("recover" used
here in the sense of simply delaying an ack such as the ipv4 case
discussed earlier, for example) without side effects (like a failed
syscall) should specify __GFP_NOWARN.

Page allocation failures have emitted warnings for all gfp masks without
__GFP_NOWARN since 2.5.53 over six and a half years ago.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at