From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Chris Snook <csnook@redhat.com>,
Dave Jones <davej@codemonkey.org.uk>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Linux Kernel <linux-kernel@vger.kernel.org>,
NetDev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: GFP_ATOMIC page allocation failures.
Date: Wed, 02 Apr 2008 11:37:57 -0700 [thread overview]
Message-ID: <47F3D285.7030404@intel.com> (raw)
In-Reply-To: <47F3CE10.1060903@garzik.org>
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
this:
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.
Auke
next prev parent reply other threads:[~2008-04-02 18:51 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-01 23:56 GFP_ATOMIC page allocation failures Dave Jones
2008-04-02 1:28 ` Nick Piggin
2008-04-02 1:35 ` Dave Jones
2008-04-02 6:28 ` Chris Snook
2008-04-02 7:56 ` Andrew Morton
2008-04-02 8:17 ` KOSAKI Motohiro
2008-04-02 8:24 ` David Miller
2008-04-02 8:43 ` Andrew Morton
2008-04-02 10:00 ` KOSAKI Motohiro
2008-04-02 10:56 ` KOSAKI Motohiro
2008-04-02 18:44 ` David Miller
2008-04-02 20:12 ` Michael Chan
2008-04-02 20:53 ` David Miller
2008-04-02 11:04 ` Peter Zijlstra
2008-04-02 18:45 ` David Miller
2008-04-02 19:06 ` Jeff Garzik
2008-04-02 9:12 ` Nick Piggin
2008-04-02 15:54 ` Andrew Morton
2008-04-03 5:22 ` Nick Piggin
2008-04-03 5:32 ` Andrew Morton
2008-04-03 8:59 ` Evgeniy Polyakov
2008-06-26 21:06 ` Dave Jones
2008-06-26 22:26 ` Chris Snook
2008-06-26 22:26 ` Chris Snook
2008-06-27 10:01 ` Evgeniy Polyakov
2008-06-27 10:01 ` Evgeniy Polyakov
2008-04-02 17:21 ` Jeff Garzik
2008-04-02 17:33 ` Andrew Morton
2008-04-02 18:18 ` Jeff Garzik
2008-04-02 18:37 ` Kok, Auke [this message]
2008-04-03 5:57 ` Nick Piggin
2008-04-03 18:20 ` Jeff Garzik
[not found] <adYyJ-20N-11@gated-at.bofh.it>
[not found] ` <aef6w-6rx-45@gated-at.bofh.it>
[not found] ` <aefJ9-7KR-15@gated-at.bofh.it>
[not found] ` <aeqF6-45P-29@gated-at.bofh.it>
2008-04-04 9:52 ` Bodo Eggert
2008-04-04 9:52 ` Bodo Eggert
2008-04-04 10:59 ` Nick Piggin
2008-04-04 11:35 ` Bodo Eggert
2008-04-05 1:06 ` Nick Piggin
2008-04-06 12:12 ` Bodo Eggert
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=47F3D285.7030404@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=akpm@linux-foundation.org \
--cc=csnook@redhat.com \
--cc=davej@codemonkey.org.uk \
--cc=davem@davemloft.net \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=torvalds@linux-foundation.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.