public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 */



  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