On Monday 21 January 2013, Greg KH wrote:
I don't know a lot about USB, but I always assumed that this was not
a normal condition and that there are only a couple of URBs per endpoint
used at a time. Maybe Greg or someone else with a USB background can
shed some light on this.
There's no restriction on how many URBs a driver can have outstanding at
once, and if you have a system with a lot of USB devices running at the
same time, there could be lots of URBs in flight depending on the number
of host controllers and devices and drivers being used.
Ok, thanks for clarifying that. I read some more of the em28xx driver,
and while it does have a bunch of URBs in flight, there are only five
audio and five video URBs that I see simultaneously being submitted,
and then resubmitted from their completion handlers. I think this
means that there should be 10 URBs active at any given time in this
driver, which does not explain why we get 256 allocations.
I also noticed that the initial submissions are all atomic but don't
need to, so it may be worth trying the patch below, which should also
help in low-memory situations. We could also try moving the resubmission
into a workqueue in order to let those be GFP_KERNEL, but I don't think
that will help.