On Mon, 12 Jul 2010, Oliver Neukum wrote: > 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. Even without any media, the device file still gets opened and closed a couple of times in quick succession during initial probing. And although that 100-ms value is currently hard-coded, it could easily be changed to a sysfs attribute that userspace could reduce after probing is finished. (Come to think of it, autosuspend should be forbidden anyway during probing, so maybe that delay isn't really needed. However I have an intuitive feeling that _some_ autosuspend delay should always be used.) Bear in mind also that there are some commands which can legitimately be sent even in the absence of media (things like INQUIRY -- the kernel wouldn't send them but programs sometimes do). > > 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. Maybe... I don't have enough experience with different kinds of devices to know for sure. On the other hand, usb-storage devices aren't leaf nodes in the device tree, only in the USB subtree. Maybe that's what you meant: everything other than hubs. It's worth mentioning that even when usb-storage's delay gets set to 0, the effective delay would still be 100 ms because it would be determined by the SCSI delay. > > > > 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? Depends on the device. For some the cost is 0 because the device doesn't support it. On others it's very expensive, both in terms of time required and wear-and-tear. For those drives you'd want the SCSI-level delay to be much longer than 100 ms -- perhaps something like 15 minutes. Of course this delay isn't needed if there's no media... but then those drives generally don't have removable media. > > > 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. Not necessarily. Some other program could try to open the device and use it before the next poll interval ends. Besides, the driver doesn't know how long the poll intervals are. > > 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? I'm not sure what you mean. We are talking about two different criteria for idleness: device file closed vs. no medium present. My patches use one, yours/Sarah's uses the other (in a rather awkward way). My patches can be extended to use both criteria if anybody wants to do so; yours/Sarah's can't. Either way, the idleness information gets used by initiating an autosuspend. Alan Stern -- 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
