On Fri, Oct 28, 2011 at 12:56:25PM -0700, Brink, Peter wrote: > I concur with Alan. > > If there is only a single instance of xhci_urb_to_transfer_ring(), it > is more likely that this function will be resident in the processor's > cache, making the opposite to be true; performance would improve based > upon the number of times this function is called, object code > notwithstanding. The instance of xhci_urb_to_transfer_ring() in xhci.c is only used when an URB is canceled, which is very rare. The instance in xhci-ring.c would be called again and again as URBs complete. Wouldn't the function in xhci-ring.c be cached properly in the common case? Sarah > -----Original Message----- > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Alan Stern > Sent: Friday, October 28, 2011 8:11 AM > To: Sarah Sharp > Cc: Andiry Xu; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] xHCI: Remove duplicate functions > > On Fri, 28 Oct 2011, Sarah Sharp wrote: > > > On Fri, Oct 28, 2011 at 05:05:58PM +0800, Andiry Xu wrote: > > > There're two static xhci_urb_to_transfer_ring() implementations in xhci.c > > > and xhci-ring.c, and they do exactly the same things. > > > > > > Remove one of them to get rid of duplicate codes. > > > > NAK. There are the same functions in two separate files for performance > > reasons. This function is used very often, and allowing it to be static > > lets the compiler optimize it. > > Optimize it how? The only optimization for static functions that I'm > aware of is to put them inline. But this function is sufficiently long > and complicated that putting in inline would yield worse object code, > not better. > > Have you measured the performance difference? > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
