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.) > 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? 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. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings.
signature.asc
Description: This is a digitally signed message part
