> > Try the patch below. It should improve code generation too. > > > > I discussed this with Tomas previously and he says the hw is capable of > > doing 20 fragments per frame (wonder why, Broadcom can do an unlimited > > number...) but he complained about the networking stack not being able > > to. > > This is scatter gather buffers that can be kicked in one DMA transaction. > > Well, the hardware needs to support IP checksumming for that, hence, > > afaik, only two fragments can ever be used (one for hw header, one for > > frame) > This I still don't understand why but everybody is already tired to > explaining me why.. :) Just need to find time to dig into it. And you can safely decrease the allocation to 10% as I do in my patch because once you understand you'll see that you cannot possibly use more. Hence, you can ack this patch ;) > > This cuts the allocation to 10%, or (under) a page in all cases. > > Probably. it would be safe to use vmalloc for allocating txb anyway. > I'll give it a try. Yeah, but why bother if we can just allocate 10% of the size, waste a lot less memory etc. mac80211 isn't going to pass in a scatter/gather frame anyway. > There was already discussion on LKML about memory allocation problems > on X86_64, which might explain this regression. This didn't happen > before. Doesn't really matter, iwlwifi is _wasting_ this allocation, it cannot possibly use all those buffers anyway. The more interesting thing is the pci_alloc_consistent allocation right below that is also _huge_, but that's because of the stupid hardware design, or can the hardware cope with having the descriptors non-linear in memory? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
