On Thursday 26 November 2009, Alan Stern wrote: > On Wed, 25 Nov 2009, Rafael J. Wysocki wrote: > > > On Wednesday 25 November 2009, Alan Stern wrote: > > > Rafael: > > > > > > It turns out that I need a pm_schedule_idle() routine. > > > pm_schedule_suspend() just doesn't do what I want -- I need the > > > runtime_idle() callback to be invoked when the timer expires, not > > > runtime_suspend(). > > > > > > Adding the routine itself is easy enough, but the obvious way to > > > implement it is to use dev->power.request to tell the timer function > > > whether it should queue an idle or a suspend. This leads to a problem: > > > It becomes impossible to queue an idle request if there's a scheduled > > > suspend. The reason is that power.request has to remain set to > > > indicate that a suspend should be queued when the timer expires, so it > > > can't be changed to RPM_REQ_IDLE. > > > > > > One possible way around this would be to have pm_schedule_idle() > > > completely replace pm_schedule_suspend(). This seems like a reasonable > > > approach -- at the time of the function call we don't know what > > > conditions will be like in the future, so when the timer expires we > > > should check again to see if a suspend is appropriate. > > > > > > What do you think? > > > > I'm against that. In fact I have a usage case that would be broken by this > > change. > > > > What exactly is your usage scenario? > > Never mind, I figured out how to do what I want without it. This > involves lying a little to the runtime PM core. I'm going to tell it > that the interfaces in a USB device are suspended whenever their usage > counts drop to 0, even though the interface drivers' suspend routines > won't get called until the overall device is suspended. Likewise, I'll > call the drivers' resume routines when the device is resumed, even > though the PM core will still think the interfaces are suspended. I don't see any problems with that. > I don't think that will cause any problems. The alternative -- > informing the PM core about the interfaces' true states -- is a lot > more troublesome. (Even when the interfaces are idle and have a usage > count of 0, the fact that they aren't actually suspended will prevent > idle notifications from being delivered for the device, making it > difficult to know when the device should be suspended.) Agreed. > Here's a related matter for you to consider. Let's say I want a device > to suspend after N milliseconds of inactivity. Thus, when an I/O > operation completes I will call pm_schedule_suspend(dev, N). That's > fine if the amount of activity is low. > > However if the device is very active, like a disk drive or network > interface in constant use, this will add a significant overhead to > every I/O. An alternative approach is simply to store the time when an > I/O completes, without rescheduling the suspend. Then the > runtime_suspend method can compare the current time to the stored time, > and fail with -EAGAIN if the difference is less than N ms. The > runtime_idle method will be called, and it can schedule another suspend > in the future. > > This is perfectly workable, although I don't know how active the device > has to be before this strategy is preferable. How many times do you > have to reschedule a timer before it requires more overhead than just > letting the timer expire and the workqueue run? Probably a lot -- it's > not easy to tell. Somewhere between 100 and 1000 maybe? Unfortunately I don't have much experience with that, so I can't really say. > Anyway, the one drawback of this approach (not very significant) is > that it requires the runtime_suspend method to do the time check. In > principle, such checks should be performed instead by the runtime_idle > method. But that's not possible here without the ability to schedule > an idle notification in the future. > > Like I said, this is a very minor drawback. Agreed again. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
