Christian Lamparter wrote: > This patch tries to address a long standing issue: > how to survive serve memory starvation situations, > without losing the device due to missing transfer-buffers. > > And with a flick of __GFP_NOWARN, we're able to handle ?all? memory > allocation failures on the rx-side during operation without much fuss. > > However, there is still an issue within the xmit-part. > This is likely due to p54's demand for a large free headroom for > every outgoing frame: > > + transport header (differs from device to device) > -> 16 bytes transport header (USB 1st gen) > -> 8 bytes for (USB 2nd gen) > -> 0 bytes for spi & pci > + 12 bytes for p54_hdr > + 44 bytes for p54_tx_data > + up to 3 bytes for alignment > (+ 802.11 header as well? ) > > and this is where ieee80211_skb_resize comes into the play... > which will try to _relocate_ (alloc new, copy, free old) frame data, > as the headroom is most of the time simply not enough. > => > Call Trace: (from Larry - Bug #13319 ) > [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e > [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6 > [<ffffffff802b6362>] new_slab+0xcf/0x28b > [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd > [<ffffffff802b672e>] __slab_alloc+0x210/0x44c > [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166 > [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166 > [<ffffffff802b7e60>] __kmalloc+0x119/0x194 > [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166 > [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211] > [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211] > [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8 > (sl*b debug option will help to bloat even more.) > > So?! how to prevent ieee80211_skb_resize from raping > the bits of memory left? > > the simplest answer is probably this one: > https://dev.openwrt.org/changeset/15761 Christian, I have not had a change to review and/or test this patch. I applaud attempts to reduce memory, but the problem that I reported will be fixed in 2.6.31. Whenever the SLUB debugging would force the order of the request to increase, debugging will be turned off for that request and a notification will be logged. This solution represents a compromise among the developers - as usual none of them are really happy with this approach, and it is expected that there will be further development for 2.6.32. After I test this patch, I will try reverting the change that reduced MTU on the chance that it will no longer be necessary. 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
