On Friday 12 April 2002 20:01, Petko Manolov wrote:
> > IMHO draining the pool about 50% and then refill it in
> > one go would be much more efficient.
>
> The pool doesn't change the efficiency. At all. I tested the driver
> with and without rx skb cache and there was no difference. Looks like
> the bottleneck is in the usb bus itself, not in the memory allocation.
> I introduced the pool mainly to reduce the time spend in interrupt.
Well done. Though you could reduce cpu consumption to benefit
the rest of the system.
> > 2. You cannot assume that submission in the tasklet will work
> > if it failed in the completion handler. In fact the opposite is likely.
>
> I am not assuming this. If submission fail the status will be checked
> next time the tasklet run and resubmit it if needed. The current
> algorithm relys on uncoditional tasklet_schedule() based on the
> assumption the time spend in the tasklet is minimal.
Yes, but if submission fails in the completion handler and in
the tasklet, which can happen due to depletion of the atomic
pool, the tasklet will not be scheduled a second time, as
only the completion handler will reliably schedule the tasklet.
5. You do not lock against concurrent tasklets. IMHO with sufficiently
bad luck two tasklets can try to submit the rx urb at the same time.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
