diff mbox

[E1000-devel,e100] Page allocation failure warning(?) in 2.6.36.3

Message ID 1294853710.3981.108.camel@edumazet-laptop
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Eric Dumazet Jan. 12, 2011, 5:35 p.m. UTC
Le mardi 11 janvier 2011 à 12:59 -0800, Chris Rankin a écrit :
> Tushar,
> 
> As promised:
> 
> $ /sbin/ifconfig -a
> br0       Link encap:Ethernet  HWaddr 00:03:47:3b:29:5c  
>           inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
>           inet6 addr: fe80::203:47ff:fe3b:295c/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:372485 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:383917 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0 
>           RX bytes:37566127 (35.8 MiB)  TX bytes:225458273 (215.0 MiB)
> 
> eth0      Link encap:Ethernet  HWaddr 00:90:27:76:d0:ec  
>           inet addr:10.0.43.2  Bcast:10.0.43.255  Mask:255.255.255.0
>           inet6 addr: fe80::290:27ff:fe76:d0ec/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:432016 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:377602 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:229629017 (218.9 MiB)  TX bytes:41958103 (40.0 MiB)
> 
> eth1      Link encap:Ethernet  HWaddr 00:03:47:3b:29:5c  
>           inet6 addr: fe80::203:47ff:fe3b:295c/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:364683 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:369235 errors:1 dropped:0 overruns:0 carrier:1
>           collisions:0 txqueuelen:1000 
>           RX bytes:42445811 (40.4 MiB)  TX bytes:203414933 (193.9 MiB)
> 
> eth2      Link encap:Ethernet  HWaddr 00:03:47:3b:29:5d  
>           inet6 addr: fe80::203:47ff:fe3b:295d/64 Scope:Link
>           UP BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:9059 errors:1 dropped:0 overruns:0 frame:1
>           TX packets:15437 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:691449 (675.2 KiB)  TX bytes:22232699 (21.2 MiB)
> 
> lo        Link encap:Local Loopback  
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           RX packets:797 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:797 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0 
>           RX bytes:81543 (79.6 KiB)  TX bytes:81543 (79.6 KiB)
> 
> $ cat /etc/network/interfaces 
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> # The primary network interface
> allow-hotplug eth0
> iface eth0 inet static
> 	address 10.0.43.2
> 	netmask 255.255.255.0
> 	network 10.0.43.0
> 	broadcast 10.0.43.255
> 	gateway 10.0.43.1
> 	# dns-* options are implemented by the resolvconf package, if installed
> 	dns-nameservers 192.168.0.1
> 	dns-search underworld
> 
> auto br0
> iface br0 inet static
> 	address 192.168.0.1
> 	netmask 255.255.255.0
> 	network 192.168.0.0
> 	broadcast 192.168.0.255
> 	bridge-ports eth1 eth2
> 	bridge_hello 1
> 	bridge_fd 4
> 	bridge_maxage 4
> 	post-up /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev br0
> 
> Cheers,
> Chris
> 

Apparently e100 driver uses GFP_ATOMIC allocations in setup phase, and
your machine doesnt have enough memory.

I would try following patch, allowing the use of GFP_KERNEL at init
time, to let vm games play.

Thanks

[PATCH] e100: use GFP_KERNEL allocations at device init stage

In lowmem conditions, e100 driver can fail its initialization, because
of GFP_ATOMIC abuse.

Switch to GFP_KERNEL were applicable.

Add __GFP_NOWARN flag to GFP_ATOMIC allocations, since driver can cope
with failed allocations (if setup succeeded)

Reported-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Chris Rankin Jan. 12, 2011, 5:42 p.m. UTC | #1
--- On Wed, 12/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Apparently e100 driver uses GFP_ATOMIC allocations in setup
> phase, and your machine doesnt have enough memory.

Thanks. You'd think 64 MB of RAM would be enough... ;-).

Cheers,
Chris


      
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Eric Dumazet Jan. 12, 2011, 5:48 p.m. UTC | #2
Le mercredi 12 janvier 2011 à 09:42 -0800, Chris Rankin a écrit :
> --- On Wed, 12/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Apparently e100 driver uses GFP_ATOMIC allocations in setup
> > phase, and your machine doesnt have enough memory.
> 
> Thanks. You'd think 64 MB of RAM would be enough... ;-).

I remember using linux on a 8MB machine a loooong time ago, but not a
2.6 kernel :)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jesse Brandeburg Jan. 12, 2011, 6:05 p.m. UTC | #3
Hi Eric, thanks for doing this work!

On Wed, 12 Jan 2011, Eric Dumazet wrote:
> Apparently e100 driver uses GFP_ATOMIC allocations in setup phase, and
> your machine doesnt have enough memory.

This part looks great.
 
> I would try following patch, allowing the use of GFP_KERNEL at init
> time, to let vm games play.
> 
> Thanks
> 
> [PATCH] e100: use GFP_KERNEL allocations at device init stage
> 
> In lowmem conditions, e100 driver can fail its initialization, because
> of GFP_ATOMIC abuse.
> 
> Switch to GFP_KERNEL were applicable.
> 
> Add __GFP_NOWARN flag to GFP_ATOMIC allocations, since driver can cope
> with failed allocations (if setup succeeded)
> 
> Reported-by: Chris Rankin <rankincj@yahoo.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>

> -		if (unlikely(e100_rx_alloc_skb(nic, rx)))
> +		if (unlikely(e100_rx_alloc_skb(nic, rx,
> +					       GFP_ATOMIC | __GFP_NOWARN)))

First, I don't think the following comment should hold up this patch.

As a policy question when I asked about using __GFP_NOWARN before in other 
Intel ethernet drivers the consensus seemed to be that the warning 
messages were useful.  All our drivers correctly handle runtime memory 
failures, but none of them are currently using __GFP_NOWARN.

Can I submit patches to change our other drivers to __GFP_NOWARN?  I think 
it will make for quite a few less reports of non-issues to the list.  All 
our drivers that I would be patching already have ethtool counters that 
count failed allocations.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index b0aa9e6..e4d8a70 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -1880,9 +1880,21 @@  static inline void e100_start_receiver(struct nic *nic, struct rx *rx)
 }
 
 #define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN)
-static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
+
+static struct sk_buff *e100_alloc_skb(struct net_device *dev, gfp_t flags)
+{
+	struct sk_buff *skb;
+
+	skb = __netdev_alloc_skb(dev, RFD_BUF_LEN + NET_IP_ALIGN, flags);
+	if (NET_IP_ALIGN && skb)
+		skb_reserve(skb, NET_IP_ALIGN);
+	return skb;
+}
+
+static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx, gfp_t flags)
 {
-	if (!(rx->skb = netdev_alloc_skb_ip_align(nic->netdev, RFD_BUF_LEN)))
+	rx->skb = e100_alloc_skb(nic->netdev, flags);
+	if (!rx->skb)
 		return -ENOMEM;
 
 	/* Init, and map the RFD. */
@@ -2026,7 +2038,8 @@  static void e100_rx_clean(struct nic *nic, unsigned int *work_done,
 
 	/* Alloc new skbs to refill list */
 	for (rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) {
-		if (unlikely(e100_rx_alloc_skb(nic, rx)))
+		if (unlikely(e100_rx_alloc_skb(nic, rx,
+					       GFP_ATOMIC | __GFP_NOWARN)))
 			break; /* Better luck next time (see watchdog) */
 	}
 
@@ -2102,13 +2115,13 @@  static int e100_rx_alloc_list(struct nic *nic)
 	nic->rx_to_use = nic->rx_to_clean = NULL;
 	nic->ru_running = RU_UNINITIALIZED;
 
-	if (!(nic->rxs = kcalloc(count, sizeof(struct rx), GFP_ATOMIC)))
+	if (!(nic->rxs = kcalloc(count, sizeof(struct rx), GFP_KERNEL)))
 		return -ENOMEM;
 
 	for (rx = nic->rxs, i = 0; i < count; rx++, i++) {
 		rx->next = (i + 1 < count) ? rx + 1 : nic->rxs;
 		rx->prev = (i == 0) ? nic->rxs + count - 1 : rx - 1;
-		if (e100_rx_alloc_skb(nic, rx)) {
+		if (e100_rx_alloc_skb(nic, rx, GFP_KERNEL)) {
 			e100_rx_clean_list(nic);
 			return -ENOMEM;
 		}