Re: [PATCH] Moving spinlock to struct usb_hcd

2008-01-27 Thread Greg KH
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

Re: [PATCH] Moving spinlock to struct usb_hcd

2008-01-27 Thread Romit Dasgupta
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

Re: [PATCH] Moving spinlock to struct usb_hcd

2008-01-26 Thread Romit Dasgupta
> > > 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

Re: [PATCH] Moving spinlock to struct usb_hcd

2008-01-26 Thread David Brownell
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

[PATCH] Moving spinlock to struct usb_hcd

2008-01-25 Thread Romit Dasgupta
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