Sorry for the missing description, I've submitted it several times so I just assumed that the previous entries in the thread were enough. I'll resubmit with a full description. As for replacing sd_resume altogether, the reason I didn't is because there are three callbacks which use sd_resume. I've only tested this functionality for the system resume call, not restore or runtime_resume, and I didn't know if the other two made sense as asynchronous since it doesn't really buy anything in runtime_resume, but I understand your point that it adds unnecessary complexity. I'll fix it. I'm sure there are no issues but I'll be sure and test all the new scenerios before I resubmit. So, with fixes to those two issues, do you think this technique is something you'd accept? I've tried it two different ways, one where I changed the pm code to allow nonblocking resume callbacks, which just finalized system resume without waiting for the ata and scsi drivers to finish. But that didn't fly well with Rafael as it violates some implicit assumptions about how the callbacks function. I worked with Rafael to come up with a "skip_resume" version which just skipped the system resume of the disks, changed them to runtime suspended, and let them runtime resume whenever they were accessed, but it proved to be impractical in a real OS environment because the OS tends to access everything at once when it comes back online. This approach is really the only remaining way (that I can think of) to remove the ata-port wakeup delay in software, so given the massive performance benefit I hope you'll consider it. Thanks for the reply! On Fri, Sep 06, 2013 at 08:10:34AM -0700, James Bottomley wrote: > On Thu, 2013-09-05 at 17:44 -0700, Todd E Brandt wrote: > > Part 2 of the hard disk resume optimization patch, this one applies > > to the scsi subsystem. > > This is a horrible patch description, it won't tell the next reader > anything about what is going on and why. Give the patches two separate > summaries and refer back by summary explaining what this one does. > > Also, having two code paths do the same thing is always a bad idea: > someone will update one and not the other. sd_resume() should be come > sd_resume_async(); wait for async event > > James > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
