Ben Hutchings <b...@decadent.org.uk> writes: > On Mon, 2016-04-11 at 09:55 +0200, Bjørn Mork wrote: >> Ben Hutchings <b...@decadent.org.uk> writes: >> > >> > On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote: >> > > >> > > It works for the most part, but floods syslog with messages: >> > > >> > > [501966.870273] net_ratelimit: 35702 callbacks suppressed >> > > [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped >> > > >> > > It seems to function ok, though I'm not sure if there's degraded >> > > network performance... >> > [...] >> > >> > I understand network performance on all RPi models is poor due to lack >> > of a built-in Ethernet MAC and the poor design of the USB interface. >> > Also that message is a generic error message from the usbnet core and >> > is not specific to the smsc95xx driver. >> Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet >> based device under memory pressure. The usbnet framework just doesn't >> handle the case where GFP_KERNEL allocations fail. How could it? > > What I don't understand, given this, is why Vagrant didn't report any > OOM warnings. (I wondered whether the __GFP_NOWARN flag was wrongly > being added somewhere, but I don't see that.)
Maybe I'm wrong? Looking at this again, I notice that rx_submit() always will call usb_submit_urb(urb, GFP_ATOMIC) regardless of the input mem_flags, because it's holding a spinlock when submitting the urb. So it doesn't necessarily help much that the urb and skb are allocated with GFP_KERNEL. Exactly what allocations usb_submit_urb() may end up with seems to be depending on the host controller. So the error spam could very well be caused by a problematic host controller. At least partly. >> The only viable "fix" I can see is by preallocating and recycling all >> buffers instead of the repeated allocations done by usbnet now. But >> that's a major refactoring of usbnet. >> >> The log message spam could of course be fixed, but the rate-limiting is >> "good enough". > > How is anyone supposed to know what "kevent 2" is though? By looking it up in include/linux/usb/usbnet.h :) Yes, that could certainly be improved by translating the number back to a readable description. > The drivers that support batching into large RX buffers should > automatically fall back to smaller buffers if this happens, or whenever > they're running on a small (for some definition of small) machine. I > understand that the dynamic fallback may be tricky though. I don't think the smsc95xx use any large buffers. Looks like it's an ethernet packet + 12 bytes. And usbnet limits the total rx queue to 60 * 1518 bytes. Bjørn
