PS: You should use a small schedule_timeout() instead of yield. kswapd needs time to do its job.
Maybe. But _any_ action performed, irq handler or task progress or whatever, could free the necessary resources. When resources are that tight, waiting longer might let some other activity get them. And it's more likely to be lower-priority too ... why not give the scheduler more input to those decisions?
This is where some real system measurements would help judge how further work might best proceed. Since the UHCI hardware is the most demanding in terms of TD memory allocations, it'd likely be easiest to stress that. Try "testusb -t5" (through "-t8") for a scatterlist stress load, through UHCI on a low-memory setup. It'd be interesting to know if that retry logic provokes trouble of any kind. I suspect other problems would hide it for quite a while ... and they'd also would appear under less-extreme loads! - Dave ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
