Re: timers and busy detection

Am Donnerstag, 22. März 2007 18:07 schrieb Alan Stern:
> On Thu, 22 Mar 2007, Oliver Neukum wrote:
> 
> > Hi,
> > 
> > I'd like to make the following change to autosuspend:
> > 
> > --- linux-2.6.21-rc4-git6/include/linux/usb.h.alt	2007-03-22 14:26:26.000000000 +0100
> > +++ linux-2.6.21-rc4-git6/include/linux/usb.h	2007-03-22 14:28:18.000000000 +0100
> > @@ -155,6 +155,9 @@
> >  	struct device dev;		/* interface specific device info */
> >  	struct device *usb_dev;		/* pointer to the usb class's device, if any */
> >  	int pm_usage_cnt;		/* usage counter for autosuspend */
> > +	spinlock_t			suspend_time_lock;
> > +	unsigned long			last_busy;
> > +	unsigned long			last_elevated;
> >  };
> >  #define	to_usb_interface(d) container_of(d, struct usb_interface, dev)
> >  #define	interface_to_usbdev(intf) \
> 
> I'm fine with adding last_busy; in fact I'm planning on it.  (But perhaps
> it will be named "last_used".)
> 
> I'm not so sure about suspend_time_lock -- only a few devices will need it
> and it could just as easily go into the driver's private data structure.  
> Maybe a lot of drivers will end up needing it and it should go into the
> core, but that seems unlikely.
> 
> I don't understand last_elevated at all.  If the device's usage count is 
> currently above 0, wouldn't last_elevated be equal to last_busy?  Is it 
> just meant for keeping track of how long the device was in use?
> 
> > To avoid manipulating timers in autosuspend for usb storage, I propose
> > that the timer is killed only if autosuspend_delay > jiffies - last_elevated.
> > Otherwise it is kept running and last_busy can be used to calculate whether
> > enough time has elapsed.
> > 
> > Might it be sensible to fire up a timer for longer than autosuspend_delay if
> > the check fails often?
> 
> 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. 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.
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.

	Regards
		Oliver

-------------------------------------------------------------------------
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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel