On Mon, Jan 13, 2014 at 03:30:07PM -0500, Tejun Heo wrote: > Hello, > > On Mon, Jan 13, 2014 at 11:55:44AM -0800, Todd E Brandt wrote: > > I see your point, why have two paths if one will do. The only thing that > > worries me is that the PM resume from hibernate function doesn't have > > an error handler. What happens when it tries to read the image from swap > > and the disk is still spinning up? The scsi layer has an error handler so > > The request gets blocked on EH. > > > it just keeps retrying every few seconds, but the PM core reads directly > > from the swap disk's block device. > > Why would that matter? Resume is handled by EH. While EH is in > progress, all commands are blocked. Am I missing something? No, I am. You're right, there shouldn't be an issue. I'm just sketchy about new changes that I haven't tested. Lemme code up the change and do some stress testing to be sure there are no issues. > > > > So, can't just everything become async? Are there cases where we > > > *need* synchronous PM behaviors? > > > > I think suspend still needs to be synchronous, because the PM core needs > > to be sure that the disks are actually spun down before it can attempt > > to shut the system down. I'm adding Raphael to the thread. Raphael, is > > this correct? > > Yeah, we definitely should wait for suspend to complete before > entering suspend state. I was referring to the resume path. Ahh, sorry, yea I think async should work for the entire resume pathway. Would you be willing to accept this ata patch separately from the scsi one? It wouldn't provide any performance benefit on its own, but would pave the way for performance benefit by removing the ATA resume lag time (Which would then put the ball in the scsi layer's court to finish the optimization). I've tested both patches separately and both work without issue. Also, this patch appears to be a pre-requisite to both mine and Phillip Susi's solution, so it would really hope move things along regardless of which direction is ultimately chosen in the SCSI layer. > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
