[lkml]   [2008]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: GFP_ATOMIC page allocation failures.
    Jeff Garzik wrote:
    > Andrew Morton wrote:
    >> After you've read Nick's comments (which I pray you have not), and after
    >> you've convinced us and yourself of their wrongness, you might like to
    >> consider adding a __GFP_NOWARN to netdev_alloc_skb().
    > Already done so. Adding __GFP_NOWARN to netdev_alloc_skb() is wrong
    > for several reasons.
    > It doesn't change the underlying conditions.
    > It doesn't fix the desire to stamp other drivers in this manner.
    > And most importantly, it is not even correct: the handling of the
    > allocation failure remains delegated to the netdev_alloc_skb() users,
    > which may or may not be properly handling allocation failures.
    > Put simply, you don't know if the caller is stupid or smart. And there
    > are a _lot_ of callers, do you really want to flag all of them?
    > Many modern net drivers are smart, and quite gracefully handle
    > allocation failure without skipping a beat.
    > But some are really dumb, and leave big holes in their DMA rings when
    > allocations fail.
    > The warnings are valid _sometimes_, but not for others. So adding
    > __GFP_NOWARN to netdev_alloc_skb() unconditionally makes no sense,
    > except as an admission that the "spew when there is memory pressure"
    > idea was silly.
    > Turning to Nick's comment,
    >> It's still actually nice to know how often it is happening even for
    >> these known good sites because too much can indicate a problem and
    >> that you could actually bring performance up by tuning some things.
    > then create a counter or acculuation buffer somewhere.
    > We don't need spew every time there is memory pressure of this magnitude.
    > IMO there are much better ways than printk(), to inform tasks, and
    > humans, of allocation failures.

    FYI e1000 and family already count various levels of alloc failures resulting from

    alloc_rx_buff_failed - page alloc failure (might be harmless)
    rx_no_buffer_count - no buffer available for HW to use (harmless, hw will retry)
    rx_missed_errors - hw dropped a packet because of above failures

    still I personally think the page alloc warnings are a good thing and we've had
    several issues resolve quickly because of them.

    shutting them up completely moves the focus to our driver which ends up being a
    victim of suspicion, and we have to circle around hard to convince the user otherwise.


     \ /
      Last update: 2008-04-02 20:53    [W:0.064 / U:4.508 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site