On Sunday, 3 September 2006 18:25, David Singleton wrote: > On 9/2/06, Rafael J. Wysocki <rjw at sisk.pl> wrote: > > On Saturday 02 September 2006 20:05, David Singleton wrote: > > > On 8/29/06, Matthew Locke <matthew.a.locke at comcast.net> wrote: > > > > > > > > On Aug 29, 2006, at 10:49 AM, Preece Scott-PREECE wrote: > > > > > > > > > > > > > >> From: linux-pm-bounces at lists.osdl.org > > > > >> [mailto:linux-pm-bounces at lists.osdl.org] On Behalf Of Pavel Machek > > > > >> Sent: Tuesday, August 29, 2006 11:35 AM > > > > >> To: David Singleton > > > > >> Cc: linux-pm at lists.osdl.org > > > > >> Subject: Re: [linux-pm] So, what's the status on the recent > > > > >> patches here? > > > > >> > > > > >> Hi! > > > > >>>>> point, by name. There is a new > > > > >>>> /sys/power/operating_points directory > > > > >>>>> that shows all the operating points the > > > > >>>> system supports. An > > > > >>>>> exampled from my centrino laptop shows: > > > > >>>>> > > > > >>>>> /sys/power/operating_points/high > > > > >>>>> /sys/power/operating_points/highest > > > > >>>>> /sys/power/operating_points/low > > > > >>>>> /sys/power/operating_points/lowest > > > > >>>>> /sys/power/operating_points/medium > > > > >>>>> /sys/power/operating_points/mem > > > > >>>>> /sys/power/operating_points/standby > > > > >>>> > > > > >>>> What makes you think that mixing operating and sleep > > > > >> states is good > > > > >>>> idea? > > > > >>> > > > > >>> They are all power states managed by the kernel and in the > > > > >> operating > > > > >>> point concept they are all operating points the system supports. > > > > >> > > > > >> That does not make mixing them right. > > > > > --- > > > > > > > > > > Could you say why you think they shouldn't be mixed? Absent argument to > > > > > the contrary, > > > > > making it a single continuum seems appealing. Why have separate > > > > > policies? > > > > > > > > I know this questions is directed at Pavel but I have similar concerns. > > > > I agree that making sleep states into operating points is appealing. > > > > However, if the implementation is just going to special case the sleep > > > > state operating points then they should be handled separately. As > > > > Pavel points out, you can see from Dave's implementation that the > > > > operating point definition doesn't quite work for both. Voltage and > > > > frequency don't have meaning for the sleep points. > > > > > > Actually what I was trying, unsuccessfully, to explain was that > > > suspend states are valid, supported operating states the > > > system can be in for power management. And that they are the > > > same as an operating point for a processor frequency. > > > > 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 the 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 and I think that's a good enough reason to handle them separately. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller
