On Mon, 2016-03-21 at 14:24 -0400, Alan Stern wrote: > On Mon, 21 Mar 2016, Oliver Neukum wrote: > > > On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote: > > > > > One possible solution is to export a sysfs parameter to prevent > > > statistics collection (or more generally, to change the interval at > > > which it occurs). > > > > Surely, not performing a task can hardly be beaten in terms of power > > consumption. That is not meant to be flippant, but I think these > > issues are orthogonal. The question of how much to do doesn't > > solve the question of doing efficiently what we do. > > In other words, what's the best way to collect the statistics without > interfering with runtime PM, right? Yes. > If the device is suspended, presumably we know there's nothing to > collect -- especially if we already collected the statistics at the > time the device got suspended. Hence my suggestion to avoid querying > the device while it is suspended. That is perfectly alright if we just collect statistics. As a generic mechanism it is bad. Think about the polling for media detection. > But this leaves open the issue that querying the device too often will > prevent it from going into autosuspend. It seems to me that the best > way to deal with this is to make sure that the autosuspend timeout is > shorter than the interal between queries, not to make the querying > conditional on !runtime_auto. [..] > > If we know when the next activity will come, why not pass this > > information down? We have an autosuspend timeout because we think that IO, if it will come at all, is likeliest to come soon. If, however, the IO is periodic that heuristics is false. To save most power the driver must either decide that the interval is too short or suspend immediately. So if we are lucky enough to have the frequency in the kernel, we should use that information. 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
