Am Montag, 12. Juli 2010, 17:32:56 schrieb Alan Stern: > On Mon, 12 Jul 2010, Oliver Neukum wrote: > > > > I don't see how it affects the topic of this discussion, though. It > > > means that suspending whenever you learn there is no media will yield > > > essentially the same result as suspending whenever the device file is > > > closed. > > > > If you suspend as soon as you close, yes. If you use the heuristics > > of waiting a little time before you suspend, no. > > My SCSI patches use a 100-ms delay. This was necessary because during > initial probing of a new disk, the device file gets opened and closed > several times in quick succession. Exactly. As you can see the delay benefits you if and only if a medium is present. > On the other hand, usb-storage's delay could be set to 0 with no ill > effects. Leading to the question whether this should be the default for every non-leave node in the device tree. > > > As for the time required... I have thought several times that perhaps > > > we should have an "autosuspend_ms" attribute in addition to (if not > > > instead of) the "autosuspend" file. While delays much shorter than 50 > > > or 100 ms don't make any sense, that still leaves a lot of room between > > > 50 and 1000 ms, which is the shortest we can currently accomodate. > > > > The people at Sony/Ericsson tested that with cdc-acm. No useful > > power savings. It might be different with storage. > > It might be different with storage _and_ probing every few seconds. > The real benefit here is not so much the delay for the storage device, > but rather the autosuspend delay for the parent hub. But how expensive is a spin down/up cycle? > > The feature of a driver letting the core know that the device will be idle > > from now on for some time. > > Well, in fact you _don't_ know how long the device will be idle. > Perhaps the user is already inserting a new medium. Yes, but we'll learn this only at the next poll. So it will be idle for a known time. > The basic scheme should be very simple. A driver tells the core that > its device is currently idle by means of the usual autosuspend function > calls. Deciding what to do then is up to the core, as determined by > the configurable policy settings set by userspace. This seems to be a waste to me. If we know we will be idle, why not use the knowledge? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
