[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080402175857.959A.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date: Wed, 02 Apr 2008 19:00:25 +0900
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: David Miller <davem@...emloft.net>
Cc: kosaki.motohiro@...fujitsu.com, akpm@...ux-foundation.org,
csnook@...hat.com, davej@...emonkey.org.uk,
nickpiggin@...oo.com.au, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, Michael Chan <mchan@...adcom.com>
Subject: Re: GFP_ATOMIC page allocation failures.
Hi
> > if network guys hope known-good driver should call
> > __netdev_alloc_skb(dev, length, GFP_ATOMIC|__GFP_NOWARN) instead netdev_alloc_skb,
> > I think we should make netdev_alloc_skb_nowarn.
>
> Giving it a proper name like this takes away the indication that this
> situation is very special.
Hmmm,
at least, tg3 driver often output the same message on my test environment.
(because I often run stress test ;)
I doubt almost driver has the same problem under heavy workload.
and I think tg3 is known-good driver too.
because its alloc failure doesn't cause any bad thing at all.
Do you favorite the following patch?
---------------------------------------------------------------------
We get rather a lot of reports of page allocation warnings coming out of
tg3. But this driver is know to handle them properly so let's suppress
them.
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
CC: David Miller <davem@...emloft.net>
CC: Andrew Morton <akpm@...ux-foundation.org>
CC: Michael Chan <mchan@...adcom.com>
---
drivers/net/tg3.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Index: b/drivers/net/tg3.c
===================================================================
--- a/drivers/net/tg3.c 2008-03-14 21:38:12.000000000 +0900
+++ b/drivers/net/tg3.c 2008-04-02 18:54:15.000000000 +0900
@@ -307,6 +307,11 @@ static const struct {
{ "interrupt test (offline)" },
};
+static inline void *tg3_alloc_skb(struct net_device *dev, unsigned int length)
+{
+ return __netdev_alloc_skb(dev, length, GFP_ATOMIC|__GFP_NOWARN);
+}
+
static void tg3_write32(struct tg3 *tp, u32 off, u32 val)
{
writel(val, tp->regs + off);
@@ -3437,7 +3442,7 @@ static int tg3_alloc_rx_skb(struct tg3 *
* Callers depend upon this behavior and assume that
* we leave everything unchanged if we fail.
*/
- skb = netdev_alloc_skb(tp->dev, skb_size);
+ skb = tg3_alloc_skb(tp->dev, skb_size);
if (skb == NULL)
return -ENOMEM;
@@ -3609,7 +3614,7 @@ static int tg3_rx(struct tg3 *tp, int bu
tg3_recycle_rx(tp, opaque_key,
desc_idx, *post_ptr);
- copy_skb = netdev_alloc_skb(tp->dev, len + 2);
+ copy_skb = tg3_alloc_skb(tp->dev, len + 2);
if (copy_skb == NULL)
goto drop_it_no_recycle;
@@ -9370,7 +9375,7 @@ static int tg3_run_loopback(struct tg3 *
err = -EIO;
tx_len = 1514;
- skb = netdev_alloc_skb(tp->dev, tx_len);
+ skb = tg3_alloc_skb(tp->dev, tx_len);
if (!skb)
return -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists