From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Scott E. Preece" Subject: Re: So, what's the status on the recent patches here? Date: Sun, 3 Sep 2006 18:00:56 -0500 (CDT) Message-ID: <200609032300.k83N0uL6016830@olwen.urbana.css.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-reply-to: "Rafael J. Wysocki"'s message of Mon, 4 Sep 2006 00:10:47 +0200 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.osdl.org Errors-To: linux-pm-bounces@lists.osdl.org To: rjw@sisk.pl Cc: scott.preece@motorola.com, matthew.a.locke@comcast.net, linux-pm@lists.osdl.org, pavel@ucw.cz List-Id: linux-pm@vger.kernel.org | From: "Rafael J. Wysocki" | = | On Sunday, 3 September 2006 23:34, Scott E. Preece wrote: | > = | > | From: "Rafael J. Wysocki" | > | = | > | On Sunday, 3 September 2006 18:25, David Singleton wrote: | > | > On 9/2/06, Rafael J. Wysocki wrote: | > | > > | > | > > That depends on the definition, but I think of suspend states as = the ones | > | > > that require processes to be frozen before they can be entered. = IMHO it is | > | > > quite clear that such states cannot be handled in the same way as= those | > | > > that do not require the freezing of processes, so they are not th= e same. | > | > = | > | > You are correct, processes do need to be frozen before a suspend. | > | > That's the prepare to suspend part of the suspend process, and | > | > the transtition is the suspending and finish is the un-freezing | > | > of the processes to resume execution. | > | > = | > | > And those same steps are the same steps required to transition the | > | > system to a new operating point, whether it's suspend or change | > | > from 1.4GHz to 600MHz. | > | = | > | There are only a few states that require the processes to be frozen a= nd I | > | think that's a good enough reason to handle them separately. | > = | > --- | > = | > But, surely that distinction can be handled in the implementation behind | > the interface, rather than exsposed in the interface. | = | I don't think you can handle that behind the interface in a satisfactory = way. | For example during a suspend to disk we carry out several transitions of | devices within the suspend-resume cycle. | = | > Does that distinction matter to the policy manager? | = | I think so. | = | > I would argue that it = | > increases the latency, which would be important to the policy manager, | > but that the nature of the latency isn't important to making a policy | > decision, and the proposed interface already exposes the latency as | > something that can be used in making transition decisions. | = | From the policy manager perspective it may be just a latency fator, | but for all of the things _outside_ of the policy manager it's much more | than that. | = | For example transitions like a CPU frequency change are transparent for k= ernel | threads, but the suspend "transitions" are not, because the kernel thread= s need | to be informed that the system is suspending and they are expected to fre= eze | themselves voluntarily. | = | Really, I think that the "states" which are entered only after tasks are | frozen should be considered as special and handled separately. --- My point is that if the only kernel interface is set-op(), then the code in the kernel that implements set-op() is the thing that's going to drive the details of suspending the system, just as it does today. The abstraction at the kernel interface is about as simple as it can be and all the policy issues are moved outside the kernel. My question is whether there are aspects of suspending, other than latency, that the policy manager would need to consider in deciding whether to suspend or not. Look at it this way. In one scheme the policy manager code is: new_OP =3D select_transition(current_OP, decision_factors); set_OP(new_OP); in the other the policy manager code is: new_OP =3D select_transition(current_OP, decision_factors); if (new_OP =3D=3D SUSPEND) suspend(); else set_OP(new_OP); The only practical difference is whether the kernel has one interface or two; in the one-interface case, there's code in the kernel's implementation of set_OP() that does the same conditional and calls the same implementation of suspend. In Pavel's preferred idiom, the calls to set_OP() are replaced by a sequence of set_power_parameter(PARM, VALUE) calls All dreadfully oversimplified, of course, but I know that the general approach is possible, because our PM subsystem works in a vaguely similar manner. The simplification isn't completely ignorable, though, because the mechanisms driving the transitions involve input from the kernel (entry to idle, interrupts, clock events, load information, etc.). The interaction between the kernel and the policy manager may actually be too complex to support doing all of policy management in user space (our implementation actually has some kernel bits and some user-spec bits). Not sure that affects the question of whether suspend is an operating point, though - that seems (to me) to work the same whether the policy decision is in the kernel or in user space. The one question that I see as interesting on that score is whether the policy decision to suspend is based on factors that are wholly different than the factors that drive frequency/voltage changes. If that were the case, then there would be no point to making the decisions in the same place. Honestly, I'm not sure of the answer to that... scott -- = scott preece motorola mobile devices, il67, 1800 s. oak st., champaign, il 61820 = e-mail: preece@motorola.com fax: +1-217-384-8550 phone: +1-217-384-8589 cell: +1-217-433-6114 pager: 2174336114@vtext.com