> > > Looking at how this lock is used, contention doesn't look likely > to be an issue. It's never held for long ... yes in the general case but in usb_hcd_flush_endpoint routine it seems to be held for longer than other routines. I agree that usb_hcd_flush_endpoint is an infrequently called routine. Normal systems dont have too many HCs. My computer shows 1 EHCI and 3 OHCIs so I guess when I connect high speed devices there are less chances of contention. With more HC this lock might be contended for. Nevertheless, the right place for the lock seems to be inside usb_hcd. What do you think?
> > > Do you have any proof that contention is an actual problem? > Because otherwise I see no benefit to such a change. > I will try to see what I can find with /proc/lock_stat. Thanks, -Romit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
