On 04/12/2011 04:22 PM, Johannes Stezenbach wrote:
I don't think the allocation uses the MTU, rather rt2x00queue_alloc_rxskb() uses some hw specific constants. No idea if these can be reduced, but multi-page GFP_ATOMIC allocations can easily fail.
That is likely. Those hw specific constants add up to 40 bytes, thus the major part is actual buffer. That is set at 3840 bytes, thus I don't understand why the request was order 1.
However, I'm not sure why an 8kB allocation fails if the oom dump says 2*8kB are available. I guess it has something to do with the GFP_ATOMIC.
My guess is that those 8kB buffers were freed between the failure and the dump. The actual allocation is done by dev_alloc_skb() through a call to __alloc_skb() with GFP_ATOMIC, thus we have no chance to change this.
@Igor: The buffer size is set in the define for AGGREGATION_SIZE located in drivers/net/wireless/rt2x00/rt2x00queue.h. Reducing that will cut the buffer size request, but might not help the problem.
Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
