Re: So, what's the status on the recent patches here?

David Singleton
2006-08-30T04:52:26Z

On 8/29/06, Pavel Machek <pavel@ucw.cz> wrote:
> 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.

Both OpPoint and PowerOp are going to 'mix' frequency, voltage
and sleep states into their operating point concepts.

The point was not to make it look like I was mixing sleep states and
CPU frequency states, but to present all the power states
supported by the system in one place and with one interface. It simplifies
not only kernel code, but power manager code as well.

>
> > The system can be set to any of the supported states by
> > setting their name in the /sys/power/state file. I find
> > simplicity
> > is usually a good thing.
>
> I believe the quote is 'make it as simple as possible but not
> simpler'.
>
> > >And '600MHz' makes lot more sense than 'lowest' on
> > >centrino.
> >
> > Perhaps, but the common name space makes it easy for the
> > power manager
> > daemon to perform the same functions without having to
> > know that the lowest
> > speed on my laptop is 600Mhz.
>
> And enumerate english strings in power daemon? Limiting the numver of
> states?

Hah, I didn't think of it that way. I was thinking in the same way
"mem" and "disk" and "standy" are strings in the kernel.

The names themselves don't mean anything other than to imply an order so the
kernel and power manager can understand the same order.

I have the oppointd daemon running on systems of different architectures
and different numbers of operating points. Some have only two operating
points defined, some have three, some have five and one has six.

The power manager functions the same on all of them because of the ordering
presented by the names.

The oppointd daemon also understands that the operating points associated
with the names may be sparsely populated. The daemon can still work
correctly on a sparsely populated name space because of the ordering
implied. It works unchanged
on systems with only two states and on systems with six states.

>
> > >
> > >> /sys/power/operating_points/high/frequency
> > >> /sys/power/operating_points/high/voltage
> > >> /sys/power/operating_points/high/latency
> > >
> > >What is voltage for 'mem'?
> >
> > I don't know what the voltage or latency is for mem.
> > Perhaps Intel could better
> > say what the voltage is in the suspend state and what
> > the latency was
> > for transistion to that state. I didn't have the data
> > available when
> > I wrote the code.
>
> And you will not have data available even if intel helps you. What is
> _frequency_ for mem? These fields are meaningless for sleep states;
> that should tell you that mixing sleep and operating states is bad
> idea.

Actually the SoC concerns that both OpPoint and PowerOp are trying
to deal with have different power consumption levels associated with
different sleep states.

Different sleep states have different power consumption levels
and different transition latencies. The power manager needs to
understand both the power consumption level with each
sleep state and the transition latency so it can make decisions
about when to transition into different sleep states.

Typically sleep states with the lowest power consumption have
the longest transition latencies. The power manager must know
the power consumption and transition latencies so it can decide when best to
switch to a sleep state that consumes a bit more power but has
a much shorter latency to switch into and out of, and
when it's okay to switch to the lowest sleep state, but longest
transition latency.

>
> --
> Thanks for all the (sleeping) penguins.
>