Folks: I would like to tie together separate email threads regarding disk spin-up time during system resume. Todd has posted some patches to make spin-up occur asynchronously, thus not delaying the return of the system to normal operation. Phillip and I have been designing an approach to allow disks to remain spun-down until they are needed, by putting them into runtime suspend. In other words, even though some disks may spin up all by themselves when the system wakes up, we may be able to avoid immediately spinning up the others. To implement this approach will require a few small changes to the runtime PM core and the block layer core. I can take care of them fairly easily; the difficult part lies in getting the sd driver to do the right thing. The basic outline of our approach goes like this. The sd driver will get a new resume_early callback routine, which will: Check to see if the user has enabled runtime PM for this disk, if the runtime usage counter is at 0, if the request queue is empty, and so on. Basically, anything that should prevent the disk from going into runtime suspend. If all the conditions are met, set the disk's runtime PM status to RPM_SUSPENDED. Otherwise set it to RPM_ACTIVE. Then when the regular sd_resume routine runs, it will do this: If the runtime PM status is RPM_ACTIVE, issue a START-STOP command to spin up the disk, the same as sd_resume does now. (And of course, the command can be skipped if the manage_start_stop flag isn't set.) Otherwise, check to see whether the disk is spinning up all by itself. This presumably will involve issuing a TEST UNIT READY command and checking the sense data. Maybe something different will be needed for ATA disks; I don't know. If the disk is spinning, or if you can't tell, call pm_runtime_resume() to put the disk back into the RPM_ACTIVE state (and spin it up in the case where you couldn't tell what it was doing). Since the START-STOP and TEST UNIT READY (or REQUEST SENSE or whatever) commands are likely to take a long time, they should all be carried out asynchronously with respect to the resume procedure. I don't know what the best way is to implement this. But it is important to guarantee that in the RPM_ACTIVE case, the START-STOP command gets sent to the disk before any other commands. (This isn't an issue in the RPM_SUSPENDED case, as the block layer will prevent requests being sent out unless they have the REQ_PM flag set.) Does this plan sound reasonable to everyone? Are there important aspects I haven't considered (such as interactions between the SCSI and ATA layers)? Alan Stern -- 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
