On Thu, 7 Apr 2011 10:26:27 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 6 Apr 2011, Kristen Carlson Accardi wrote: > > > The thing is - once you move to a threaded irq, my resume issue > > is pretty much not going to impact anyone else, even if you leave > > the get/put calls exactly where I have them in the patch. Basically, > > unless you are a strange whacky piece of hardware like Moorestown, > > you will never get an irq while you are suspended. > > Why do you say that? Do you think standard PC hardware (with its > shared IRQs) is wacky? I was thinking about this last night, and I realized that I wasn't thinking of the shared interrupts correctly. One thing we could do to take care of the shared interrupts while in suspend issue would be to make a flag that would indicate whether the device can receive irqs as a wake up source. Then, in the irq handler you could check if you are suspended, and if the flag is not set then you can ignore the irq, otherwise you would need to wake up and see if it is for you. I believe this would at least get rid of the problem with having a lot of wakeups. If you wanted to optimize further, you could also only do the get/put if your device has the can_wake_irq flag (or whatever) set. > > Have you made timing/performance studies, comparing (for example) USB > disk throughput with and without threaded interrupts? > I could never do this with all the different types of hw. I suggest that if you decide to move to a threaded irq you have a long period of testing time where people can determine whether or not it impacts performance on their own hw. Just from googling I can see that tglx did some performance analysis, but you'd have to ask him what the findings were. -- 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
