On Mon, Jan 28, 2008 at 09:50:36AM +0530, Romit Dasgupta wrote:
> Hi,
> Should I go ahead and submit the patch with the usual
> "signed-off" thingie? Or is it totally useless patch that is going to
> be ignored?
Let's see some proof that it actually helps, and then we can evaluate
Hi,
Should I go ahead and submit the patch with the usual
"signed-off" thingie? Or is it totally useless patch that is going to
be ignored?
Thanks,
-Romit
On Jan 26, 2008 9:06 PM, Romit Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> >
> > Looking at how this lock is used, contention
>
>
> 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 rout
On Friday 25 January 2008, Romit Dasgupta wrote:
> This should help
> reduce contention to usb during high load where i/o is happening to
> multiple hcds.
Looking at how this lock is used, contention doesn't look likely
to be an issue. It's never held for long ...
> @@ -1106,9 +1103,9 @@ EXPORT
Hi,
This is an attempt to move the hcd_urb_list_lock to struct usb_hcd.
The lock is taken on functions that try to add/delete/use urb against a
given hcd. I have not seen any association of an urb with multiple hcds.
Hence I thought this can be moved within usb_hcd. This should help
reduce conte
5 matches
Mail list logo