On Fri, 23 Mar 2007, Oliver Neukum wrote: > > Can you explain in more detail what you want to accomplish here? I'm > > still puzzled. Are you trying to avoid letting the timer expire > > repeatedly while the device is in use for a prolonged time? > > It was my understanding that we are still working on a two level approach > An interface may increment its counter. Then it will not be autosuspended, > or it may set an activity flag, then it won't be autosuspended either, but the > flag will be reset and rechecked after the delay period. > > I propose to replace that flag with last_busy.
I agree. The flag alone is too inflexible. > Incidentally, if that is to > be at the device it needs a spinlock or it can't be monotonic. Otherwise > it would need to be at the interface. It doesn't have to be exactly monotonic. I wouldn't expect backward jumps to be big enough to matter. That is, they would be small compared to the total timeout delay. The question of whether to include a per-interface last_used value is still undecided. It would be necessary for implementing the per-interface idle-delay values you wanted. However I will probably start out with a single per-device value, leaving per-interface values for later. > If we only have one bit, we have to restart/mod the timer when the pm > count reaches zero. If the pm count goes up while the timer is running, > this is a waste. We need to have a timer if the pm count is 0. This is > imho unavoidable. But we can avoid modding it every time the pm count > cycles. > > Modding the timer is a waste if we can be reasonably sure that we'll > get another pm counter cycle before the timer expires. The most sensible > way to determine that is to store the time the pm counter last cycled. > If the time between then and now is a fraction of the delay, we can leave the > counter alone, if and only if we can deal with a counter expiring too early, > in case we guessed wrong and the burst of activity is over. We can always deal with a counter expiring too early. The handler will see that it needs to wait longer and will restart the timer. Or it will see that the device is currently in use and will do nothing at all -- the timer will be restarted when the usage count drops back to 0. What we cannot deal with is not having a running timer when the usage is 0. We would then run a large risk of not autosuspending the device at all. That's the real point behind the "burst" version of autopm_get_interface. It's a small optimization to avoid cancelling the timer when the usage is about to be incremented. But when the usage goes to 0, we _must_ start the timer if it isn't already running. Notice that this approach doesn't invole "modding" the timer at all. We either cancel it or else let it expire and then start it up again. After all, if you are going to adjust the expiration time, you're better off waiting until the last possible moment. That way you'll have the most up-to-date information about what the new expiration time should be. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
