From: reinette chatre <reinette.chatre@intel.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Frans Pop <elendil@planet.nl>,
Larry Finger <Larry.Finger@lwfinger.net>,
"John W. Linville" <linville@tuxdriver.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"ipw3945-devel@lists.sourceforge.net"
<ipw3945-devel@lists.sourceforge.net>,
Andrew Morton <akpm@linux-foundation.org>,
"cl@linux-foundation.org" <cl@linux-foundation.org>,
"Krauss, Assaf" <assaf.krauss@intel.com>,
Johannes Berg <johannes@sipsolutions.net>,
"Abbas, Mohamed" <mohamed.abbas@intel.com>
Subject: Re: iwlagn: order 2 page allocation failures
Date: Wed, 09 Sep 2009 13:05:38 -0700 [thread overview]
Message-ID: <1252526738.30150.91.camel@rc-desk> (raw)
In-Reply-To: <20090909165545.GK24614@csn.ul.ie>
Mel and Frans,
Thank you very much for digging into this.
On Wed, 2009-09-09 at 09:55 -0700, Mel Gorman wrote:
> Conceivably a better candidate for this problem is commit
> 4752c93c30441f98f7ed723001b1a5e3e5619829 introduced in May 2009. If there
> are less than RX_QUEUE_SIZE/2 left, it starts replenishing buffers. Mohamed,
> is it absolutly necessary it use GFP_ATOMIC there? If an allocation fails,
> does it always mean frames are dropped or could it just replenish what it
> can and try again later printing a warning only if allocation failures are
> resulting in packet loss?
I agree that this patch may be the reason we are seeing this issue. We
would like to keep using GFP_ATOMIC here, but it is not necessary for an
allocation failure to be so noisy since the function doing the
allocation (iwl_rx_allocate) is always followed by a call to
iwl_rx_queue_restock which will schedule a refill if the buffers are
running low. We can thus use ___GFP_NOWARN for the allocations in
iwl_rx_allocate and leave it to the restocking to find the needed memory
when it tried its allocations using GFP_KERNEL.
I do think it is useful to let user know about these allocation
failures, even if it does not result in packet loss. Wrapping it in
net_ratelimit() will help though.
How about the patch below?
diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c
index b90adcb..f0ee72e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
@@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority)
/* Alloc a new receive buffer */
skb = alloc_skb(priv->hw_params.rx_buf_size + 256,
- priority);
+ priority | __GFP_NOWARN);
if (!skb) {
- IWL_CRIT(priv, "Can not allocate SKB buffers\n");
+ if (net_ratelimit())
+ IWL_CRIT(priv, "Can not allocate SKB buffer.\n");
/* We don't reschedule replenish work here -- we will
* call the restock method and if it still needs
* more buffers it will schedule replenish */
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 0909668..5d9fb78 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1147,10 +1147,10 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority)
spin_unlock_irqrestore(&rxq->lock, flags);
/* Alloc a new receive buffer */
- skb = alloc_skb(priv->hw_params.rx_buf_size, priority);
+ skb = alloc_skb(priv->hw_params.rx_buf_size, priority | __GFP_NOWARN);
if (!skb) {
if (net_ratelimit())
- IWL_CRIT(priv, ": Can not allocate SKB buffers\n");
+ IWL_CRIT(priv, "Can not allocate SKB buffer.\n");
/* We don't reschedule replenish work here -- we will
* call the restock method and if it still needs
* more buffers it will schedule replenish */
next prev parent reply other threads:[~2009-09-09 20:05 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-06 7:40 iwlagn: order 2 page allocation failures Frans Pop
2009-09-06 8:14 ` Pekka Enberg
2009-09-06 8:28 ` Frans Pop
2009-09-06 8:35 ` Pekka Enberg
2009-09-08 10:54 ` Mel Gorman
2009-09-08 11:11 ` Pekka Enberg
2009-09-08 14:17 ` John W. Linville
2009-09-08 14:59 ` Larry Finger
2009-09-09 15:04 ` Mel Gorman
2009-09-09 15:59 ` Frans Pop
2009-09-09 16:55 ` Mel Gorman
2009-09-09 17:19 ` Frans Pop
2009-09-16 14:36 ` Frans Pop
2009-09-16 15:02 ` Mel Gorman
2009-09-16 15:37 ` Frans Pop
2009-09-16 16:26 ` reinette chatre
2009-09-09 20:05 ` reinette chatre [this message]
2009-09-10 1:48 ` Frans Pop
2009-09-10 9:02 ` Mel Gorman
2009-09-10 18:15 ` reinette chatre
2009-09-10 18:43 ` Frans Pop
2009-09-10 18:50 ` reinette chatre
2009-09-11 8:45 ` Mel Gorman
2009-09-11 16:14 ` reinette chatre
2009-09-10 21:14 ` reinette chatre
2009-09-11 8:47 ` Mel Gorman
2009-09-14 3:01 ` Zhu Yi
2009-09-14 13:06 ` Mel Gorman
2009-09-15 8:30 ` alloc skb based on a given data buffer Zhu Yi
2009-09-15 8:33 ` David Miller
2009-09-15 8:57 ` Zhu Yi
2009-09-15 9:09 ` David Miller
2009-09-15 9:15 ` Zhu Yi
2009-09-15 15:30 ` Johannes Berg
2009-09-15 21:16 ` David Miller
2009-09-19 5:56 ` Johannes Berg
2009-09-14 15:42 ` iwlagn: order 2 page allocation failures Christoph Lameter
2009-09-14 17:59 ` Mel Gorman
2009-09-14 18:04 ` Christoph Lameter
2009-09-10 8:18 ` Pekka Enberg
2009-09-10 12:34 ` Mel Gorman
2009-09-10 12:39 ` Pekka Enberg
2009-09-10 12:58 ` Mel Gorman
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=1252526738.30150.91.camel@rc-desk \
--to=reinette.chatre@intel.com \
--cc=Larry.Finger@lwfinger.net \
--cc=akpm@linux-foundation.org \
--cc=assaf.krauss@intel.com \
--cc=cl@linux-foundation.org \
--cc=elendil@planet.nl \
--cc=ipw3945-devel@lists.sourceforge.net \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mel@csn.ul.ie \
--cc=mohamed.abbas@intel.com \
--cc=penberg@cs.helsinki.fi \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox