Control: tag -1 moreinfo On Wed, 2017-10-11 at 18:09 -0300, Rogério Brito wrote: > Hi, Ben. > > On Oct 11 2017, Ben Hutchings wrote: > > On Wed, 2017-10-11 at 11:48 -0300, rbr...@ime.usp.br wrote: > > > I am using an armel system with only 128MB of RAM (a KuroBox Pro) running > > > Debian testing and, if my memory serves me well, I started seeing lots and > > > lots of messages like: > > > > > > mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize skb > > > with tiny unaligned fragment > > > > > > on my dmesg after I upgraded to kernel 4.12. I don't know if this is a > > > serious problem or only a cosmetic issue. > > > > [...] > > > > This message and the code that generates it have been present in the > > mv643xx_eth driver for a long time. The network interface hardware is > > generally capable of transmitting a packet that comes from multiple > > buffers in memory, but in some cases the driver copies all the data > > into a single buffer, probably to avoid a hardware bug. If there is > > not enough memory to make that copy then it logs this message. > > Oh, thanks for the explanation. > > > I think the driver should drop the packet if this happens, but instead > > it just reports that the hardware is busy. That will cause the kernel > > to try sending the packet again repeatedly, resulting in repetition of > > this log message until there is more memory available. > > Hummm, that may be related to some lower performance that I have felt (but > not measured). > > I see. Discarding the packet would flag congestion with TCP, if I understand > it correctly. > > > If you haven't seen this error message before, it might be triggered by an > > application change. But I think it's more likely to be caused by higher > > memory usage or fragmentation of memory. > > Yes, I think that the problem is that the programs are getting bigger and > bigger. Would setting vm.min_free_kbytes to a higher value worth it?
It might help, depending on how large the packets get. This driver supports TCP Segmentation Offload which means it can be asked to send 'packets' of up to 64K (which are split into multiple packets on the wire). It is very unlikely that it will be able to allocate a large enough buffer to do that. Whether it will ever get a packet that large depends on many factors. Now that I look at it, though, that hardware bug already has to be handled separately for TSO so maybe the full packet copy should only be done for normal packets. > Anyway, I just upgraded to kernel 4.13 and I will report what I see. OK. I think we can take this upstream after that. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin
signature.asc
Description: This is a digitally signed message part
