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

[David Rientjes]

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 
complexity.

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/