> > > Can you give an upper bound on the amount of memory needed ? > > > > That's all a function of the URB that's submitted ... including all the > > factors I mentioned, and a few more. A given URB clearly needs > > a certain number of TDs; a different URB can need more (or less) > > even if it's the same size (and type) transfer. > > But surely there must be some upper boundary of memory usage ?
Submit a bigger buffer in the URB, it'll generally need more TDs. The details are HC-specific. Clearly there's a bound derived from the size of physical memory... there might be a smaller one derived from the biggest request that'll be made by the VM, if there is such a limit. > > > Unfortunately, to be safe in the writeout path, no memory at all must be > > > allocated > > > > That sounds like the problem is rather overconstrained. > > Surely there's a more reasonable characterization of the > > issue than that ... > > I am afraid not. > .... > > Because nfs can deal with network packets being lost. > Whether this happens on the wire or due to a lack of memory > doesn't matter. > ... > This is not the case for block devices. Either it works > or it doesn't. You can defer a scsi command, but only > before you queue it. But ... since NFS allocates memory, and it works for paging, then there IS some more reasonable characterization. The usb-storage code could retry when it gets "-ENOMEM" when submitting an URB, to get similar effects, yes? - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
