On Wed, 2012-05-16 at 11:59 -0400, Alan Stern wrote: > On Wed, 16 May 2012, Lin Ming wrote: > > > > Lin, you should have more slack timer handling. Look at the blk-timeout > > > handling of request timeouts for inspiration, and/or the thread that > > > Jeff also references. Doing a timer add/del for each request put is a no > > > go. > > > > You mentioned how to detect queue idle in the referenced thread: > > > > === > > So we could probably add an idle timer that is set to some suitable > > timeout for this and would be added when the queue first goes empty. If > > new requests come in, just let it simmer and defer checking the state to > > when it actually fires. > > That is basically how the runtime PM timer works, if you use it as I > described earlier. > > > === > > > > What do you mean of "the queue first goes empty"? > > When the queue is first created, the timer is started. > > Whenever the timer expires, the code checks to see if any requests have > been processed since the previous expiration. If they have, the timer > is restarted. If they haven't, you suspend the device. And the timer is restarted when we resume the device, right? > > 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
