Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757907AbcCUTXx (ORCPT ); Mon, 21 Mar 2016 15:23:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:48155 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757373AbcCUTXv (ORCPT ); Mon, 21 Mar 2016 15:23:51 -0400 Message-ID: <1458586269.9609.14.camel@suse.com> Subject: Re: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM From: Oliver Neukum To: Alan Stern Cc: "David S. Miller" , Geert Uytterhoeven , Microchip Linux Driver Support , Woojung Huh , "Rafael J. Wysocki" , Guenter Roeck , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, netdev@vger.kernel.org Date: Mon, 21 Mar 2016 19:51:09 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1910 Lines: 48 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