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

I'm seeing a lot of threads without very much resolution on the differing patches that are flying around here in regards to the rework of the power management stuff (not suspend stuff...)

So, should I just grab a random patchset from here and add it to my trees and get it into -mm for testing, or does someone want to possibly guide me to the set that everyone seems to agree apon?

Or, is there two (or more) competing patch sets here that need to get resolved?

(If you can't tell I'm getting a bit annoyed at having to tell people all the time that yes, power management on Linux is bad, and yes, people
are working on it, but no, I have no idea when it will ever see the light of day...)

thanks,

greg k-h
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

I am a little concerned that none of the cpufreq developers have responded. I was hoping to get their feedback.

Quoted 5 lines

(If you can't tell I'm getting a bit annoyed at having to tell people all the time that yes, power management on Linux is bad, and yes, people
are working on it, but no, I have no idea when it will ever see the light of day...)

Well, we are working on it.

Quoted 2 lines · Matthew Locke

I am a little concerned that none of the cpufreq developers have responded. I was hoping to get their feedback.

I was waiting for the dust to settle before spending a significant amount of time reviewing. I have to admit, the two patchsets thing did confuse me too. (Though I've also been swamped with bugs since I got back from OLS, so I've appreciated the breathing room :)

If we're arriving any closer to consensus on whats mergable from the cpufreq side, and what needs more input, I'll find the time to review soon, but there still seems to be ongoing discussion which is why I decided to leave it sort itself out :)

Quoted 8 lines

Quoted 6 lines

(If you can't tell I'm getting a bit annoyed at having to tell people all the time that yes, power management on Linux is bad, and yes, people
are working on it, but no, I have no idea when it will ever see the light of day...)

Well, we are working on it.

Sadly powerop is but a tiny piece of the puzzle.

Dave

Signature · 1 line

http://www.codemonkey.org.uk

Quoted 4 lines

If we're arriving any closer to consensus on whats mergable from the cpufreq side, and what needs more input, I'll find the time to review soon, but there still seems to be ongoing discussion which is why I decided to leave it sort itself out :)

I think we are at the stage of need more input on the last set of Eugeny's patches. (the ones I point to in my email) The cpufreq patches, so far, are more for example. We need a bit of work before they are ready for merging. However, I would prefer to have your feedback now rather than later.

This adds a whole bunch of new code, and doesn't seem to make any existing code any simpler (to me at least). From a cpufreq point of view, what does adding this buy us? What problem do we have today that is being solved by all this?

Every explanation of powerop I've seen so far dives into microdetails, whilst the 10,000ft view has always passed me by other than "this is what we've had in the embedded world".

The diagram at http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html
also confuses me. I was under the impression that powerop was adding additional userspace interfaces. If we're not changing how things from a userspace point of view, we're churning a lot of kernel code,.. why?

Clue me in here, I'm feeling thick.

Quoted 14 lines

This adds a whole bunch of new code, and doesn't seem to make any existing code any simpler (to me at least). From a cpufreq point of view, what does adding this buy us? What problem do we have today that is being solved by all this?

Every explanation of powerop I've seen so far dives into microdetails, whilst the 10,000ft view has always passed me by other than "this is what we've had in the embedded world".

The diagram at http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html
also confuses me. I was under the impression that powerop was adding additional userspace interfaces. If we're not changing how things from a userspace point of view, we're churning a lot of kernel code,.. why?

Quoted 1 line

Clue me in here, I'm feeling thick.

You're not alone, I really don't get it either.

But I guess we'll just wait for the next round of unified patches and then go from there.

Quoted 15 lines · Dave Jones

This adds a whole bunch of new code, and doesn't seem to make any existing code any simpler (to me at least). From a cpufreq point of view, what does adding this buy us? What problem do we have today that is being solved by all this?

Every explanation of powerop I've seen so far dives into microdetails, whilst the 10,000ft view has always passed me by other than "this is what we've had in the embedded world".

The diagram at http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html
also confuses me. I was under the impression that powerop was adding additional userspace interfaces. If we're not changing how things from a userspace point of view, we're churning a lot of kernel code,.. why?

Quoted 1 line

Clue me in here, I'm feeling thick.

You're not alone, I really don't get it either.

But I guess we'll just wait for the next round of unified patches and then go from there.

Here is my shot at providing a 10,000ft view:

a. For embedded platforms, cpufreq just does not cut it when specifying an operating point for the device. These platforms use tuples such as

<voltage, pll_freq, core1_freq, core2_freq, interconnect_freq>

to signify an 'operating point'. Note that core1 and core2 can be totally different processors e.g. ARM and DSP. x86 platforms hide this complexity behind ACPI.

b. The clocking and voltage dependency tree in embedded devices can be summarised in the clock framework ( find ./arch -name clock* ) and soon-to-be-available voltage framework. These is again done to large extent by ACPI on x86.

d. In the end, all this is leading to an interface for a user-space policy manager that will control _system_ power state based on constraints imposed by HW peripherals or on policies implemented by device manufacturer/distro maintainer.

At this point, PowerOP is an optional component in mainline tree. Cpufreq drivers can _choose_ to use it or not. But now embedded platforms can do the PM dance in a consistent way.

Quoted 3 lines · Amit Kucheria

Here is my shot at providing a 10,000ft view:

a. For embedded platforms, cpufreq just does not cut it when

specifying

Quoted 1 line

an operating point for the device. These platforms use tuples such

as

Quoted 5 lines

<voltage, pll_freq, core1_freq, core2_freq, interconnect_freq>

to signify an 'operating point'. Note that core1 and core2 can be totally different processors e.g. ARM and DSP. x86 platforms hide

this

Quoted 1 line

complexity behind ACPI.

If there are dependancies inherently linking core1 and core2, cpufreq should already be programming both parts. For example, the SA1100 driver programs both CPU and SDRAM controller. If there isn't any dependancy
between them, I don't see the attraction of creating an artificial one in the way suggested for no real purpose.

Things like voltage and frequency are closely tied together, so offering
any means of controlling them independantly makes no sense afaics.

Quoted 2 lines

b. The clocking and voltage dependency tree in embedded devices can

be

Quoted 2 lines

summarised in the clock framework ( find ./arch -name clock* ) and soon-to-be-available voltage framework. These is again done to

large

Quoted 1 line

extent by ACPI on x86.

Of the 14 x86 cpufreq drivers, 3 of them _optionally_ use ACPI. powernow-k7 for example doesn't use it, and is possibly one of the most
stable cpufreq drivers we've had in the tree (for x86 at least).

Quoted 4 lines

d. In the end, all this is leading to an interface for a user-space policy manager that will control _system_ power state based on constraints imposed by HW peripherals or on policies implemented by device manufacturer/distro maintainer.

How does that interface look from a userspace point of view ? Hopefully not anything like the tuple described above. Why would userspace ever care about "interconnect freq" ?

Userspace cares about "save power" or "go fast". Historically, I wish we had never exposed frequencies, but instead a performance percentage, so that the various userspace tools didn't have to care about things like 'what frequencies are available'.
Adding the same mistake for voltages doesn't strike me as a fantastic idea.

Quoted 4 lines

At this point, PowerOP is an optional component in mainline tree. Cpufreq drivers can _choose_ to use it or not. But now embedded platforms can do the PM dance in a consistent way.

That's about the only part I really like so far. The option to opt-out where it makes absolutely no sense to pointlessly abstract stuff (which for x86 seems to be the case). For ARM, I'm going to leave Russell to comment/review.

Dave

--
http://www.codemonkey.org.uk
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 7 lines

If there are dependancies inherently linking core1 and core2, cpufreq should already be programming both parts. For example, the SA1100 driver programs both CPU and SDRAM controller. If there isn't any dependancy
between them, I don't see the attraction of creating an artificial one in the way suggested for no real purpose.

Quoted 3 lines

Things like voltage and frequency are closely tied together, so offering
any means of controlling them independantly makes no sense afaics.

Yet a certain subsystem (for example an onboard camera, in a phone) might require a higher voltage when it's active, effectively loosening the tight coupling between freq and voltage that the porcessor is enforcing.

Hi!

Quoted 1 line

Quoted 1 line

If there are dependancies inherently linking core1 and core2,

cpufreq

Quoted 4 lines

Quoted 4 lines

should already be programming both parts. For example, the SA1100 driver programs both CPU and SDRAM controller. If there isn't any dependancy
between them, I don't see the attraction of creating an artificial

one

Quoted 8 lines

Quoted 5 lines

in the way suggested for no real purpose.

Things like voltage and frequency are closely tied together, so offering
any means of controlling them independantly makes no sense afaics.

Yet a certain subsystem (for example an onboard camera, in a phone) might require a higher voltage when it's active, effectively

loosening

Quoted 2 lines

the tight coupling between freq and voltage that the porcessor is enforcing.

So... you expect userland to echo high > state before camera can be used?

I'd rather have kernel automagically up the voltage when /dev/video0 is opened...

Quoted 22 lines · ext Pavel Machek

Hi!

Quoted 1 line

Quoted 1 line

If there are dependancies inherently linking core1 and core2,

cpufreq

Quoted 4 lines

Quoted 4 lines

should already be programming both parts. For example, the SA1100 driver programs both CPU and SDRAM controller. If there isn't any dependancy
between them, I don't see the attraction of creating an artificial

one

Quoted 7 lines

Quoted 5 lines

in the way suggested for no real purpose.

Things like voltage and frequency are closely tied together, so offering
any means of controlling them independantly makes no sense afaics.

Yet a certain subsystem (for example an onboard camera, in a phone) might require a higher voltage when it's active, effectively

loosening

Quoted 2 lines

the tight coupling between freq and voltage that the porcessor is enforcing.

So... you expect userland to echo high > state before camera can be used?

Quoted 2 lines

I'd rather have kernel automagically up the voltage when /dev/video0 is opened...

Not really, I meant that the CPU is not the only customer of power domains (depend on the HW design), so the relation freq <-> voltage is not always true.

Quoted 7 lines · Igor Stoppa

Quoted 6 lines · ext Pavel Machek

Hi!

Quoted 1 line

Quoted 1 line

If there are dependancies inherently linking core1 and core2,

cpufreq

Quoted 2 lines

Quoted 2 lines

should already be programming both parts. For example, the SA1100 driver programs both CPU and SDRAM controller. If there isn't

any

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

dependancy
between them, I don't see the attraction of creating an

artificial

Quoted 6 lines

Quoted 6 lines

one

Quoted 5 lines

Quoted 5 lines

in the way suggested for no real purpose.

Things like voltage and frequency are closely tied together, so offering
any means of controlling them independantly makes no sense

afaics.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Yet a certain subsystem (for example an onboard camera, in a

phone)

Quoted 8 lines

Quoted 8 lines

Quoted 1 line

might require a higher voltage when it's active, effectively

loosening

Quoted 2 lines

the tight coupling between freq and voltage that the porcessor is enforcing.

So... you expect userland to echo high > state before camera can be used?

I'd rather have kernel automagically up the voltage

when /dev/video0

Quoted 4 lines

Quoted 1 line

is opened...

Not really, I meant that the CPU is not the only customer of power domains (depend on the HW design), so the relation freq <-> voltage

is

Quoted 2 lines

not always true.

Then you need to introduce power domains and associate your devices with them, isn't it?
So if your camera appears in the same domain with CPU, the voltage of that domain will go up either with camera=on, or CPU going to higher frequency.

Quoted 33 lines · ext Alexey Starikovskiy

Quoted 7 lines · Igor Stoppa

Quoted 6 lines · ext Pavel Machek

Hi!

Quoted 1 line

Quoted 1 line

If there are dependancies inherently linking core1 and core2,

cpufreq

Quoted 2 lines

Quoted 2 lines

should already be programming both parts. For example, the SA1100 driver programs both CPU and SDRAM controller. If there isn't

any

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

dependancy
between them, I don't see the attraction of creating an

artificial

Quoted 6 lines

Quoted 6 lines

one

Quoted 5 lines

Quoted 5 lines

in the way suggested for no real purpose.

Things like voltage and frequency are closely tied together, so offering
any means of controlling them independantly makes no sense

afaics.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Yet a certain subsystem (for example an onboard camera, in a

phone)

Quoted 8 lines

Quoted 8 lines

Quoted 1 line

might require a higher voltage when it's active, effectively

loosening

Quoted 2 lines

the tight coupling between freq and voltage that the porcessor is enforcing.

So... you expect userland to echo high > state before camera can be used?

I'd rather have kernel automagically up the voltage

when /dev/video0

Quoted 3 lines

Quoted 1 line

is opened...

Not really, I meant that the CPU is not the only customer of power domains (depend on the HW design), so the relation freq <-> voltage

Quoted 8 lines

is

Quoted 2 lines

not always true.

Then you need to introduce power domains and associate your devices with them, isn't it?
So if your camera appears in the same domain with CPU, the voltage of that domain will go up either with camera=on, or CPU going to higher frequency.

I used the expression "power domain" to refer to a generic domain, either voltage or frequency, to indicate that changing either freq or voltage in a domain implies changing the domain power level.

Of course it is changing linearly with frequency, while the dependency from voltage is quadratic.

So in the camera example we might have 2 different cases:

-the one mentioned above, where the camera shares the same voltage domain with CPU and the correlation is the one you described

-another case where the clock frequency provided to the camera is related to the resolution being used

camera off => no constraints
low res => low freq, high voltage
high res => high freq, high voltage

in such case the currently active resolution would affect whatever device shares the camera clock, if any.

But no need to introduce power domains.

Quoted 8 lines · Igor Stoppa

Quoted 7 lines · ext Alexey Starikovskiy

Quoted 6 lines · Igor Stoppa

Quoted 5 lines · ext Pavel Machek

Hi!

Quoted 1 line

Quoted 1 line

If there are dependancies inherently linking core1 and core2,

cpufreq

Quoted 1 line

Quoted 1 line

should already be programming both parts. For example, the

SA1100

Quoted 11 lines

Quoted 11 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

driver programs both CPU and SDRAM controller. If there isn't

any

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

dependancy
between them, I don't see the attraction of creating an

artificial

Quoted 6 lines

Quoted 6 lines

one

Quoted 5 lines

Quoted 5 lines

in the way suggested for no real purpose.

Things like voltage and frequency are closely tied together, so offering
any means of controlling them independantly makes no sense

Quoted 6 lines

Quoted 6 lines

afaics.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Yet a certain subsystem (for example an onboard camera, in a

phone)

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

might require a higher voltage when it's active, effectively

loosening

Quoted 1 line

the tight coupling between freq and voltage that the porcessor

is

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

enforcing.

So... you expect userland to echo high > state before camera can

be

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

Quoted 3 lines

used?

I'd rather have kernel automagically up the voltage

when /dev/video0

Quoted 3 lines

Quoted 1 line

is opened...

Not really, I meant that the CPU is not the only customer of power domains (depend on the HW design), so the relation freq <->

voltage

Quoted 6 lines

Quoted 6 lines

is

Quoted 2 lines

not always true.

Then you need to introduce power domains and associate your devices with them, isn't it?
So if your camera appears in the same domain with CPU, the voltage

of

Quoted 1 line

Quoted 1 line

that domain will go up either with camera=on, or CPU going to

higher

Quoted 4 lines

Quoted 1 line

frequency.

I used the expression "power domain" to refer to a generic domain, either voltage or frequency, to indicate that changing either freq

or

Quoted 3 lines

voltage in a domain implies changing the domain power level.

Of course it is changing linearly with frequency, while the

dependency

Quoted 14 lines

from voltage is quadratic.

So in the camera example we might have 2 different cases:

-the one mentioned above, where the camera shares the same voltage domain with CPU and the correlation is the one you described

-another case where the clock frequency provided to the camera is related to the resolution being used

camera off => no constraints
low res => low freq, high voltage
high res => high freq, high voltage

Quoted 5 lines

in such case the currently active resolution would affect whatever device shares the camera clock, if any.

But no need to introduce power domains.

How about introducing a frequency domain as well?

Quoted 11 lines · Amit Kucheria

Here is my shot at providing a 10,000ft view:

a. For embedded platforms, cpufreq just does not cut it when specifying
an operating point for the device. These platforms use tuples such as

<voltage, pll_freq, core1_freq, core2_freq, interconnect_freq>

to signify an 'operating point'. Note that core1 and core2 can be totally different processors e.g. ARM and DSP. x86 platforms hide this complexity behind ACPI.

If there are dependancies inherently linking core1 and core2, cpufreq should already be programming both parts. For example, the SA1100 driver programs both CPU and SDRAM controller. If there isn't any dependancy
between them, I don't see the attraction of creating an artificial one in the way suggested for no real purpose.

Things like voltage and frequency are closely tied together, so offering
any means of controlling them independantly makes no sense afaics.

Quoted 5 lines

b. The clocking and voltage dependency tree in embedded devices can be summarised in the clock framework ( find ./arch -name clock* ) and soon-to-be-available voltage framework. These is again done to large extent by ACPI on x86.

Of the 14 x86 cpufreq drivers, 3 of them _optionally_ use ACPI. powernow-k7 for example doesn't use it, and is possibly one of the most stable cpufreq drivers we've had in the tree (for x86 at least).

Quoted 4 lines

d. In the end, all this is leading to an interface for a user-space policy manager that will control _system_ power state based on constraints imposed by HW peripherals or on policies implemented by device manufacturer/distro maintainer.

How does that interface look from a userspace point of view ? Hopefully not anything like the tuple described above. Why would userspace ever care about "interconnect freq" ?

Userspace cares about "save power" or "go fast". Historically, I wish we had never exposed frequencies, but instead a performance percentage, so that the various userspace tools didn't have to care about things like 'what frequencies are available'. Adding the same mistake for voltages doesn't strike me as a fantastic idea.

Quoted 4 lines

At this point, PowerOP is an optional component in mainline tree. Cpufreq drivers can _choose_ to use it or not. But now embedded platforms can do the PM dance in a consistent way.

That's about the only part I really like so far. The option to opt-out where it makes absolutely no sense to pointlessly abstract stuff (which for x86 seems to be the case). For ARM, I'm going to leave Russell to comment/review.

Dave

Signature · 5 lines

http://www.codemonkey.org.uk
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 5 lines · Dave Jones

If there are dependancies inherently linking core1 and core2, cpufreq should already be programming both parts. For example, the SA1100 driver programs both CPU and SDRAM controller. If there isn't any dependancy between them, I don't see the attraction of creating an artificial one in the way suggested for no real purpose.

Are you arguing against the operating point concept because it creates an artificial dependency? I assume your definition of dependency means a physical dependency.

The operating point represents both a physical and operational
dependency. It is a collection of parameters that can/will be adjusted to reduce power consumption. However, adjusting these parameters can have a severe impact to performance and operational state of the system. The parameters can not be adjusted individually and still
achieve the goal of an operational and power efficient system. SoC's
have a fixed number of values in a fixed number of combinations that keep the system operational and power efficient. Using power op, a piece of controlling software can tell the system to go to specific instance of the power parameters that provide the best combination of power savings and performance/operational integrity according to the current state of the system. This instance is represented by a string.

Quoted 5 lines

d. In the end, all this is leading to an interface for a user-space policy manager that will control _system_ power state based on constraints imposed by HW peripherals or on policies implemented by device manufacturer/distro maintainer.

How does that interface look from a userspace point of view ? Hopefully not anything like the tuple described above. Why would userspace ever care about "interconnect freq" ?

Userspace cares about "save power" or "go fast". Historically, I wish we had never exposed frequencies, but instead a performance percentage, so that the various userspace tools didn't have to care about things like 'what frequencies are available'.
Adding the same mistake for voltages doesn't strike me as a fantastic idea.

Quoted 7 lines

Userspace cares about "save power" or "go fast". Historically, I wish we had never exposed frequencies, but instead a performance percentage, so that the various userspace tools didn't have to care about things like 'what frequencies are available'.
Adding the same mistake for voltages doesn't strike me as a fantastic idea.

The userspace interface in Eungeny's patches is for other userspace programs (policy managers) to activate/deactivate valid operating points in the system dynamically and if necessary, introduce new ones into the system. It will also allow the operating points to be referenced by name instead of the tuple.

Then, we will be able to use names like 'video', 'mp3', 'fast', 'powersave', 'usb' to switch to the relevant operating point based on configuration of the policy manager.

Quoted 3 lines

Then, we will be able to use names like 'video', 'mp3', 'fast', 'powersave', 'usb' to switch to the relevant operating point based on configuration of the policy manager.

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

Quoted 4 lines

Quoted 3 lines

Then, we will be able to use names like 'video', 'mp3', 'fast', 'powersave', 'usb' to switch to the relevant operating point based on configuration of the policy manager.

Quoted 4 lines

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

I guess it just defines an appropriate policy. You can call it 'usb_mp3' if you wish ;)
I don't think it's too embedded-specific.

Quoted 3 lines · Pavel Machek

Quoted 2 lines

Quoted 2 lines

Then, we will be able to use names like 'video', 'mp3', 'fast', 'powersave', 'usb' to switch to the relevant operating point

based on

Quoted 7 lines

Quoted 6 lines

Quoted 1 line

configuration of the policy manager.

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

Quoted 3 lines

I guess it just defines an appropriate policy. You can call it 'usb_mp3' if you wish ;)
I don't think it's too embedded-specific.

Well, it leads to exponential number of policies -- not nice. Having usb_mp3_fileserver_webserver is not nice.

Quoted 6 lines

Quoted 5 lines

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

Quoted 3 lines

I guess it just defines an appropriate policy. You can call it 'usb_mp3' if you wish ;)
I don't think it's too embedded-specific.

Well, it leads to exponential number of policies -- not nice. Having usb_mp3_fileserver_webserver is not nice.

Quoted 6 lines · Pavel Machek

Quoted 6 lines

Quoted 5 lines

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

Quoted 6 lines

Quoted 3 lines

I guess it just defines an appropriate policy. You can call it 'usb_mp3' if you wish ;)
I don't think it's too embedded-specific.

Well, it leads to exponential number of policies -- not nice. Having usb_mp3_fileserver_webserver is not nice.

No. The reason is there's no _real_ difference in 'fileserver' and 'webserver' from the PM POV, so this will never happen. There's no reason to introduce different policies for different use cases which however imply similar peripherals utilization. Moreover, I never play MP3s on a fileserver/webserver. The example you've given is pretty much artificial.

Quoted 6 lines

No. The reason is there's no _real_ difference in 'fileserver' and 'webserver' from the PM POV, so this will never happen. There's no reason to introduce different policies for different use cases which however imply similar peripherals utilization. Moreover, I never play MP3s on a fileserver/webserver. The example you've given is pretty much artificial.

My notebook has 23 different devices. Do you really want to have 8388608 policies for different perihepal utilizations?

Quoted 7 lines

Quoted 6 lines

No. The reason is there's no _real_ difference in 'fileserver' and 'webserver' from the PM POV, so this will never happen. There's no reason to introduce different policies for different use cases which however imply similar peripherals utilization. Moreover, I never play MP3s on a fileserver/webserver. The example you've given is pretty much artificial.

Quoted 2 lines

My notebook has 23 different devices. Do you really want to have 8388608 policies for different perihepal utilizations?

Can you please elaborate on how this number corresponds to the reality? Looks like you don't catch what I'm saying. I'm talking about use case-driven model in which you will need to invent 8388608 use cases basically in order to have 8388608 policies. IOW, not any combination is valid within these 8388608.

Hi!

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

No. The reason is there's no _real_ difference in 'fileserver' and 'webserver' from the PM POV, so this will never happen. There's no reason to introduce different policies for different use cases which however imply similar peripherals utilization. Moreover, I never play MP3s on a fileserver/webserver. The example you've given is pretty much artificial.

Quoted 8 lines

Quoted 2 lines

My notebook has 23 different devices. Do you really want to have 8388608 policies for different perihepal utilizations?

Can you please elaborate on how this number corresponds to the reality? Looks like you don't catch what I'm saying. I'm talking about use case-driven model in which you will need to invent 8388608 use cases basically in order to have 8388608 policies. IOW, not any combination is valid within these 8388608.

I'm saying that usecase-driven model is not acceptable for a kernel. It is not kernel's business to limit user to particular usage models.

That's why your model works for closed machines like a cellphones, but is totally broken for notebook. Sorry.

Hi Pavel,

Quoted 22 lines · Pavel Machek

Hi!

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

No. The reason is there's no _real_ difference in 'fileserver' and 'webserver' from the PM POV, so this will never happen. There's no reason to introduce different policies for different use cases which however imply similar peripherals utilization. Moreover, I never play MP3s on a fileserver/webserver. The example you've given is pretty much artificial.

Quoted 8 lines

Quoted 2 lines

My notebook has 23 different devices. Do you really want to have 8388608 policies for different perihepal utilizations?

Can you please elaborate on how this number corresponds to the reality? Looks like you don't catch what I'm saying. I'm talking about use case-driven model in which you will need to invent 8388608 use cases basically in order to have 8388608 policies. IOW, not any combination is valid within these 8388608.

I'm saying that usecase-driven model is not acceptable for a kernel. It is not kernel's business to limit user to particular usage models.

Quoted 2 lines

That's why your model works for closed machines like a cellphones, but is totally broken for notebook. Sorry.

Who talks about kernel? A policy is an userspace thing. I guess we're not quite understanding each other :)

Quoted 28 lines · Vitaly Wool

Hi Pavel,

Quoted 24 lines · Pavel Machek

Hi!

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

No. The reason is there's no _real_ difference in 'fileserver' and 'webserver' from the PM POV, so this will never happen. There's no reason to introduce different policies for different use cases which however imply similar peripherals utilization. Moreover, I never play MP3s on a fileserver/webserver. The example you've given is pretty much artificial.

Quoted 8 lines

Quoted 2 lines

My notebook has 23 different devices. Do you really want to have 8388608 policies for different perihepal utilizations?

Can you please elaborate on how this number corresponds to the reality? Looks like you don't catch what I'm saying. I'm talking about use case-driven model in which you will need to invent 8388608 use cases basically in order to have 8388608 policies. IOW, not any combination is valid within these 8388608.

I'm saying that usecase-driven model is not acceptable for a kernel. It is not kernel's business to limit user to particular usage models.

That's why your model works for closed machines like a cellphones, but is totally broken for notebook. Sorry.

Quoted 2 lines

Who talks about kernel? A policy is an userspace thing. I guess we're not quite understanding each other :)

You upload policies to kernel. You want 5 policies for your cellphone, and thats fine, but I'm telling you I'd need 8388608 policies for my notebook, because devices are independent and users want separate control.

Because 8388608 policies is clearly not reasonable, powerop can not help here, and something better should be developed... like power domains someone proposed here.

(Or to say it in another words, powerop forces one big power domain, which is bad model for notebook-style machine).

Quoted 6 lines · Pavel Machek

Quoted 1 line · Vitaly Wool

On 8/26/06, Pavel Machek <[email protected]> wrote:

Because 8388608 policies is clearly not reasonable, powerop can not help here, and something better should be developed... like power domains someone proposed here.

Quoted 2 lines

(Or to say it in another words, powerop forces one big power domain, which is bad model for notebook-style machine).

I doubt notebook-style machines will ever us power op in any significant way. HPC and embedded will be the first users.

Power domains will likely build on top power op.

Power domains adds complexities themselves. Dealing with dependencies and constraints between domains will be a challenge.

Quoted 7 lines · Mark Gross

Quoted 6 lines · Pavel Machek

Quoted 1 line · Vitaly Wool

On 8/26/06, Pavel Machek <[email protected]> wrote:

Because 8388608 policies is clearly not reasonable, powerop can not help here, and something better should be developed... like power domains someone proposed here.

Quoted 5 lines

Quoted 2 lines

(Or to say it in another words, powerop forces one big power domain, which is bad model for notebook-style machine).

I doubt notebook-style machines will ever us power op in any significant way. HPC and embedded will be the first users.

I agree here... power op look useless for notebooks. But I doubt power op authors would agree...

Quoted 5 lines

Power domains will likely build on top power op.

Power domains adds complexities themselves. Dealing with dependencies and constraints between domains will be a challenge.

Once we have power domains in/solved... do we still need power op? I thought power op could be useful for solving constrains _inside_ one domain, but...

Pavel

Signature · 7 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 7 lines · Mark Gross

Quoted 6 lines · Pavel Machek

Quoted 1 line · Vitaly Wool

On 8/26/06, Pavel Machek <[email protected]> wrote:

Because 8388608 policies is clearly not reasonable, powerop can not help here, and something better should be developed... like power domains someone proposed here.

Quoted 5 lines

Quoted 2 lines

(Or to say it in another words, powerop forces one big power domain, which is bad model for notebook-style machine).

I doubt notebook-style machines will ever us power op in any significant way. HPC and embedded will be the first users.

I agree here... power op look useless for notebooks. But I doubt power op authors would agree...

Quoted 5 lines

Power domains will likely build on top power op.

Power domains adds complexities themselves. Dealing with dependencies and constraints between domains will be a challenge.

Once we have power domains in/solved... do we still need power op? I thought power op could be useful for solving constrains _inside_ one domain, but...

Quoted 14 lines · Pavel Machek

Quoted 12 lines · Mark Gross

Quoted 8 lines · Pavel Machek

Quoted 1 line · Vitaly Wool

On 8/26/06, Pavel Machek <[email protected]> wrote:

Because 8388608 policies is clearly not reasonable, powerop can not help here, and something better should be developed... like power domains someone proposed here.

(Or to say it in another words, powerop forces one big power domain, which is bad model for notebook-style machine).

I doubt notebook-style machines will ever us power op in any significant way. HPC and embedded will be the first users.

Quoted 2 lines

I agree here... power op look useless for notebooks. But I doubt power op authors would agree...

Concluding that it will be useless for notebooks may be premature.

I see powerop as the bottom of an future PM stack. As the upper layers take shape who knows what platforms will use it?

Quoted 8 lines

Quoted 4 lines

Power domains will likely build on top power op.

Power domains adds complexities themselves. Dealing with dependencies and constraints between domains will be a challenge.

Once we have power domains in/solved... do we still need power op? I thought power op could be useful for solving constrains _inside_ one domain, but...

Power domains and the components within them will likely be accessed as operating points. I think we need to build the power domain abstractions on top of operating points. This is why I want to see support for multiple power_op_driver instances or a story for how operating points are added to a running system or even platform to enable and deal with domains.

Quoted 6 lines

The userspace interface in Eungeny's patches is for other userspace programs (policy managers) to activate/deactivate valid operating points in the system dynamically and if necessary, introduce new ones into the system. It will also allow the operating points to be referenced by name instead of the tuple.

Quoted 3 lines

Then, we will be able to use names like 'video', 'mp3', 'fast', 'powersave', 'usb' to switch to the relevant operating point based on configuration of the policy manager.

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

Quoted 6 lines

Quoted 6 lines

The userspace interface in Eungeny's patches is for other userspace programs (policy managers) to activate/deactivate valid operating points in the system dynamically and if necessary, introduce new ones into the system. It will also allow the operating points to be referenced by name instead of the tuple.

Quoted 8 lines

Quoted 3 lines

Then, we will be able to use names like 'video', 'mp3', 'fast', 'powersave', 'usb' to switch to the relevant operating point based on configuration of the policy manager.

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

Switch to 'fast'?

The operating point for a use-case specifies the _minimum_ required for the use-case. You can always go up.

The system designer is responsible for 'designing' operating points that take into account multiple use-cases. Designing here refers to mapping use-cases to HW operating points.

Consider an example system with a main CPU and a DSP. To simplify discussion, lets assume 3 levels for CPU and DSP speeds and system voltage. Then, here is what an example operating-point to use-case mapping table could look like:

# CPU speed DSP speed Voltage use-case
----------------------------------------------------------

1.    high           high           high          fast, video
2.    med            high           high          
3.    med            med            med           usb[1]
4.    low            med            med           mp3
5.    low            low            low           powersave

[1] USB has voltage constraint (voltage >= med)

- Now if we are playing mp3, we switch to OP 4.

- Add usb and we switch to OP 3.
- Now our performance monitor (e.g load avg) indicates that we need more CPU processing. So we switch to OP 2.

Hi!

Quoted 19 lines

Quoted 6 lines

Quoted 6 lines

The userspace interface in Eungeny's patches is for other userspace programs (policy managers) to activate/deactivate valid operating points in the system dynamically and if necessary, introduce new ones into the system. It will also allow the operating points to be referenced by name instead of the tuple.

Quoted 8 lines

Quoted 3 lines

Then, we will be able to use names like 'video', 'mp3', 'fast', 'powersave', 'usb' to switch to the relevant operating point based on configuration of the policy manager.

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

Switch to 'fast'?

The operating point for a use-case specifies the _minimum_ required for the use-case. You can always go up.

Quoted 3 lines

The system designer is responsible for 'designing' operating points that take into account multiple use-cases. Designing here refers to mapping use-cases to HW operating points.

Yes, and that's why I argue this is unsuitable for notebook: there are just too many usecases for a notebook.

Quoted 13 lines

Consider an example system with a main CPU and a DSP. To simplify discussion, lets assume 3 levels for CPU and DSP speeds and system voltage. Then, here is what an example operating-point to use-case mapping table could look like:

# CPU speed DSP speed Voltage use-case
----------------------------------------------------------

1.    high           high           high          fast, video
2.    med            high           high          
3.    med            med            med           usb[1]
4.    low            med            med           mp3
5.    low            low            low           powersave

Quoted 1 line

[1] USB has voltage constraint (voltage >= med)

So... you take three independend parametrs and merge them into one, named parameter. Bad idea.

What about simply having these parameters:

usb on or off

cpu speed (controlled by cpufreq)

dsp speed (controlled by userspace)

Then you can have infrastructure that is able to compute system voltage from usb/cpu/dsp speed, and users stll have interface they can understand.

(How are they supposed to know if video use case is compatible with usb? They should not have to).

Quoted 1 line

- Now if we are playing mp3, we switch to OP 4.

Do you expect all mp3 playing applications to play with /sys/.../powerop-point? How do you tell if mp3's are playing? These are hard questions for a notebook.

Quoted 3 lines

- Add usb and we switch to OP 3.
- Now our performance monitor (e.g load avg) indicates that we need more CPU processing. So we switch to OP 2.

That's cpufreq job, please

Quoted 26 lines · ext Pavel Machek

Hi!

Quoted 23 lines

Quoted 6 lines

Quoted 6 lines

The userspace interface in Eungeny's patches is for other userspace programs (policy managers) to activate/deactivate valid operating points in the system dynamically and if necessary, introduce new ones into the system. It will also allow the operating points to be referenced by name instead of the tuple.

Quoted 8 lines

Quoted 3 lines

Then, we will be able to use names like 'video', 'mp3', 'fast', 'powersave', 'usb' to switch to the relevant operating point based on configuration of the policy manager.

This seems to be too specific to embedded machine.

If userspace wants to work with usb and play mp3s at the same time, what does it do?

Switch to 'fast'?

The operating point for a use-case specifies the _minimum_ required for the use-case. You can always go up.

The system designer is responsible for 'designing' operating points that take into account multiple use-cases. Designing here refers to mapping use-cases to HW operating points.

Quoted 2 lines

Yes, and that's why I argue this is unsuitable for notebook: there are just too many usecases for a notebook.

You are trying to make it sound more complex than it really is. For a notebook, as you yourself pointed out, things could be handled with the present adaptive, load-based system. So you don't need to map _every_ use-case to an operating point. So you don't need to move to use PowerOP today.

But PowerOP would allow SoC-based systems to tune the operating points to get the most out of their top-10 use-cases and sleep modes.

Quoted 15 lines

Quoted 14 lines

Consider an example system with a main CPU and a DSP. To simplify discussion, lets assume 3 levels for CPU and DSP speeds and system voltage. Then, here is what an example operating-point to use-case mapping table could look like:

# CPU speed DSP speed Voltage use-case
----------------------------------------------------------

1.    high           high           high          fast, video
2.    med            high           high          
3.    med            med            med           usb[1]
4.    low            med            med           mp3
5.    low            low            low           powersave

[1] USB has voltage constraint (voltage >= med)

Quoted 2 lines

So... you take three independend parametrs and merge them into one, named parameter. Bad idea.

But they are NOT independent parameters! Which is why we want to encapsulate them into an 'Operating Point'. We have completely failed in our effort to explain the concept of an operating point if that has been your assumption all along.

Quoted 11 lines

What about simply having these parameters:

usb on or off

cpu speed (controlled by cpufreq)

dsp speed (controlled by userspace)

Then you can have infrastructure that is able to compute system voltage from usb/cpu/dsp speed, and users stll have interface they can understand.

This is moot for the reason above - cpu/dsp/volt are NOT independent.

And USB (or any device information) is NOT part of the operating point. It is just an asynchronous constraint whose appearance/disappearance influences operating point tangentially. IOW, on some systems USB could run at any operating point, so there would be no constraint. On others, use of USB would automatically cause usb clocks to go high which in turn would switch the system to an operating point that satisfies the constraint - this is handled by clock/voltage framework.

Quoted 5 lines

Quoted 3 lines

- Add usb and we switch to OP 3.
- Now our performance monitor (e.g load avg) indicates that we need more CPU processing. So we switch to OP 2.

That's cpufreq job, please

Yes. Or more particularly, the ondemand governor, right? But load average is not the only input used to make decisions. There could be thermal alarms, battery alarms, etc. And deciding which of these conflicting inputs is given priority is a policy decision made by the device manager. We discussed some of this at the PM summit.

On Wed 2006-08-30 14:00:53, Amit Kucheria wrote:

Quoted 5 lines

You are trying to make it sound more complex than it really is. For a notebook, as you yourself pointed out, things could be handled with the present adaptive, load-based system. So you don't need to map _every_ use-case to an operating point. So you don't need to move to use PowerOP today.

Ok, but please do not try to replace cpufreq with
powerop/oppoint. That is not possible.

Quoted 2 lines

But PowerOP would allow SoC-based systems to tune the operating points to get the most out of their top-10 use-cases and sleep modes.

Question is: can we get similar savings without ugly interface powerop presents?

Quoted 4 lines

But they are NOT independent parameters! Which is why we want to encapsulate them into an 'Operating Point'. We have completely failed in our effort to explain the concept of an operating point if that has been your assumption all along.

They are independed, at least from application point of view. And that's probably right interface to present to userland. Application tells you its dsp speed desired, you take current cpu frequency requirements from cpufreq, and select ooperating point with lowest consumption based on that constraints.

Quoted 7 lines

And USB (or any device information) is NOT part of the operating point. It is just an asynchronous constraint whose appearance/disappearance influences operating point tangentially. IOW, on some systems USB could run at any operating point, so there would be no constraint. On others, use of USB would automatically cause usb clocks to go high which in turn would switch the system to an operating point that satisfies the constraint - this is handled by clock/voltage framework.

Okay, and why can't we handle _all_ the constraints in this style? Ask userspace what constraints are there, and automagically select best operating point, without having operating points explicit at userspace interface.

Quoted 5 lines

Yes. Or more particularly, the ondemand governor, right? But load average is not the only input used to make decisions. There could be thermal alarms, battery alarms, etc. And deciding which of these conflicting inputs is given priority is a policy decision made by the device manager. We discussed some of this at the PM summit.

cpufreq already knows about thermal. (There's no policy in there, you can't allow system to overheat).

cpufreq already knows about battery. (On some powernow-k8, high cpu frequencies are not available on battery power, because battery is not powerful enough). If you have aditional constraints (may not use 400MHz when battery is below 20%, because li-ion has too big internal resistancy at that point?), please use cpufreq framework to enforce them.

Is there anything cpufreq can't do?

Quoted 6 lines · ext Pavel Machek

Quoted 2 lines · Amit Kucheria

But PowerOP would allow SoC-based systems to tune the operating points to get the most out of their top-10 use-cases and sleep modes.

Question is: can we get similar savings without ugly interface powerop presents?

If I have understood correctly, your main objection is to defining new operating points from userspace?

The only other interface is the actually setting of a (named) operating point and that is _required_ to do anything useful.

Quoted 1 line

Is there anything cpufreq can't do?

- Embedded systems _want_ to deal with performance/power management in terms of Operating Points that encapsulate the complete state of the SoC (core speeds, voltages, buses speeds, etc.) instead of only CPU frequency.

- There is not much in cpufreq for handling rate propagation and dependency tracking for clocks and voltages. This is what the clock framework and the upcoming voltage framework handle quite well.

- Most implementations of cpufreq drivers have a fixed rate table (freq, voltage). With rate propagation and dependencies in SoCs, available rates can vary dynamically based on states of various cores, peripherals, etc.

5. <Crystal Ball Gazing/Wishful Thinking>
- Clock/Voltage FW <--> ACPI logical mappings allows us to use global state names in /sys/power/state for system power state transitions.

Quoted 5 lines · Dave Jones

This adds a whole bunch of new code, and doesn't seem to make any existing code any simpler (to me at least). From a cpufreq point of view, what does adding this buy us? What problem do we have today that is being solved by all this?

Quoted 11 lines

Every explanation of powerop I've seen so far dives into microdetails, whilst the 10,000ft view has always passed me by other than "this is what we've had in the embedded world".

The diagram at http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html
also confuses me. I was under the impression that powerop was adding additional userspace interfaces. If we're not changing how things from a userspace point of view, we're churning a lot of kernel code,.. why?

Clue me in here, I'm feeling thick.

You're not alone, I really don't get it either.

But I guess we'll just wait for the next round of unified patches and then go from there.

thanks,

greg k-h
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Oppoint could replace large pieces of the cpufreq code
in the kernel, most notably the policy and governor code, which I believe belongs in user space in the power manager daemon.

You'll notice that the oppoint-cpufreq.patch only touches
two files, cpufreq.c and cpufreq.h. It only creates two new interfaces
to the cpufreq frequency scaling notifier lists to support driver pre and post scaling routines, already supported in the kernel.

The oppoint-x86-centrino.patch completes the replacement
of cpufreq code by introducing the transition routine to change frequencies and creates operating points for the centrino-speedstep processors already supported by Linux.

(although I've recieved a note from Intel that the data I've copied from the centrino-speedstep cpufreq tables is known to be inaccurate and unsupported)

This code could replace cpufreq code and simplify it quite a
bit in the process. The kernel drivers that support cpufreq frequency
scaling would not have to be changed. Operating points for the rest of the processors that support cpufreq would have to be created, but as you can see it's quite a straight forward transformation from a cpufreq table to a set of operating points for a processor.

Quoted 19 lines · David Singleton

Oppoint could replace large pieces of the cpufreq code
in the kernel, most notably the policy and governor code, which I believe belongs in user space in the power manager daemon.

You'll notice that the oppoint-cpufreq.patch only touches
two files, cpufreq.c and cpufreq.h. It only creates two new interfaces
to the cpufreq frequency scaling notifier lists to support driver pre and post scaling routines, already supported in the kernel.

The oppoint-x86-centrino.patch completes the replacement
of cpufreq code by introducing the transition routine to change frequencies and creates operating points for the centrino-speedstep processors already supported by Linux.

(although I've recieved a note from Intel that the data I've copied from the centrino-speedstep cpufreq tables is known to be inaccurate and unsupported)

Quoted 7 lines

This code could replace cpufreq code and simplify it quite a
bit in the process. The kernel drivers that support cpufreq frequency
scaling would not have to be changed. Operating points for the rest of the processors that support cpufreq would have to be created, but as you can see it's quite a straight forward transformation from a cpufreq table to a set of operating points for a processor.

This only touches on the cpu frequency stuff. I am assuming that the current driver interface to the different power management states is acceptable to you?

thanks,

greg k-h

Quoted 7 lines · Greg KH

Quoted 3 lines · Dave Jones

This adds a whole bunch of new code, and doesn't seem to make any existing code any simpler (to me at least). From a cpufreq point of

view,

Quoted 2 lines

what does adding this buy us? What problem do we have today that is being solved by all this?

Greg and Dave,

there are two competing patch sets for a new power management
framework. The patch set I sent out simplifies power management,
from both the cpufreq perspective and the embedded world's view of power management.

I've renamed my patch oppoint so as not confuse it
with the powerop set from Matt Locke (which will probably make it even more confusing). I've renamed it so it can be seen as an alternative design approach, not just an alternative implementation of the same ideas. I've also incorporated suggestions from Pavel in cleaning up the original patches.

If you'd be willing to take a look at, or try out, the patches
in my patch set you should be able to see how oppoint could simplify cpufreq code. The first patch is the oppoint-cpufreq.patch and the second is the oppoint-x86-centrino.patch.

Oppoint could replace large pieces of the cpufreq code
in the kernel, most notably the policy and governor code, which I believe belongs in user space in the power manager daemon.

You'll notice that the oppoint-cpufreq.patch only touches
two files, cpufreq.c and cpufreq.h. It only creates two new interfaces
to the cpufreq frequency scaling notifier lists to support driver pre and post scaling routines, already supported in the kernel.

The oppoint-x86-centrino.patch completes the replacement
of cpufreq code by introducing the transition routine to change frequencies and creates operating points for the centrino-speedstep processors already supported by Linux.

(although I've recieved a note from Intel that the data I've copied from the centrino-speedstep cpufreq tables is known to be inaccurate and unsupported)

This code could replace cpufreq code and simplify it quite a
bit in the process. The kernel drivers that support cpufreq frequency

scaling would not have to be changed. Operating points for the rest of the processors that support cpufreq would have to be created, but as you can see it's quite a straight forward transformation from a cpufreq table to a set of operating points for a processor.

The entire patch set can be found at:

http://source.mvista.com/~dsingleton/2.6.18-rc4/

The patch set consists of:

oppoint-core.patch
oppoint-cpufreq.patch
oppoint-x86-centrino.patch
oppoint-arm-pxa27x.patch

I'll attach oppoint-cpufreq.patch to this email and send out oppoint-x86-centrino.patch next.

David

Quoted 19 lines

Quoted 6 lines

Every explanation of powerop I've seen so far dives into microdetails, whilst the 10,000ft view has always passed me by other than "this is what we've had in the embedded world".

The diagram at

http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html

Quoted 1 line

also confuses me. I was under the impression that powerop was adding

additional

Quoted 4 lines

userspace interfaces. If we're not changing how things from a userspace point of view, we're churning a lot of kernel code,.. why?

Clue me in here, I'm feeling thick.

You're not alone, I really don't get it either.

But I guess we'll just wait for the next round of unified patches and then go from there.

Quoted 8 lines

thanks,

greg k-h
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 5 lines

Quoted 2 lines

This adds a whole bunch of new code, and doesn't seem to make any existing code any simpler (to me at least). From a cpufreq point of

view,

Quoted 2 lines

what does adding this buy us? What problem do we have today that is being solved by all this?

Greg and Dave,

there are two competing patch sets for a new power management
framework. The patch set I sent out simplifies power management,
from both the cpufreq perspective and the embedded world's view of power management.

I've renamed my patch oppoint so as not confuse it
with the powerop set from Matt Locke (which will probably make it even more confusing). I've renamed it so it can be seen as an alternative design approach, not just an alternative implementation of the same ideas. I've also incorporated suggestions from Pavel in cleaning up the original patches.

If you'd be willing to take a look at, or try out, the patches
in my patch set you should be able to see how oppoint could simplify cpufreq code. The first patch is the oppoint-cpufreq.patch and the second is the oppoint-x86-centrino.patch.

Oppoint could replace large pieces of the cpufreq code
in the kernel, most notably the policy and governor code, which I believe belongs in user space in the power manager daemon.

Quoted 5 lines · Dave Jones

This adds a whole bunch of new code, and doesn't seem to make any existing code any simpler (to me at least). From a cpufreq point of view, what does adding this buy us? What problem do we have today that is being solved by all this?

Quoted 11 lines

Every explanation of powerop I've seen so far dives into microdetails, whilst the 10,000ft view has always passed me by other than "this is what we've had in the embedded world".

The diagram at http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html
also confuses me. I was under the impression that powerop was adding additional userspace interfaces. If we're not changing how things from a userspace point of view, we're churning a lot of kernel code,.. why?

Clue me in here, I'm feeling thick.

You're not alone, I really don't get it either.

But I guess we'll just wait for the next round of unified patches and then go from there.

thanks,

greg k-h
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 18 lines · David Singleton

Quoted 6 lines · Greg KH

Quoted 5 lines · Dave Jones

This adds a whole bunch of new code, and doesn't seem to make any existing code any simpler (to me at least). From a cpufreq point of view, what does adding this buy us? What problem do we have today that is being solved by all this?

Greg and Dave,

Here is the patch the provides the cpufreq functionality in an
operating point
fashion for the centrino-speedstep. Cpufreq tables are transformed
into operating
points which can be simply set by writing the name of the operating point into /sys/power/state.

Quoted 6 lines

These two patches implement the cpufreq functionality of changing
processsor
frequency and voltage. The huge amount of code that tries to make decisions about what operating point to set and which devices can be suspended or not is left to
the power manager.

Why does this replicate the cpufreq driver instead of just *using* it ? From a distro vendor standpoint, I want to offer people choice, which means with this patch we'd have both drivers compiled in, but this now means we have two sets of tables to add to every time we have new cpu support to add. Two places to look for implementation bugs etc etc.

Dave
--
http://www.codemonkey.org.uk

If I had all the existing cpufreq tables transformed into operating points I could make a patch that would remove the bulk of cpufreq code from the kernel and you'd have pretty much the same functionality without the maintenance issues the added layers and complexity bring.

Quoted 5 lines · David Singleton

If I had all the existing cpufreq tables transformed into operating points I could make a patch that would remove the bulk of cpufreq code from the kernel and you'd have pretty much the same functionality without the maintenance issues the added layers and complexity bring.

If this is going to fly at all, I think thats where we need to be headed. Having two parts of the kernel doing the same thing just seems very wrong to me.

The other alternative as suggested earlier this week would be archictures getting to 'opt out' of powerop for their cpufreq drivers where it doesn't necessarily bring anything but the layer of indirection.

I'm about to disappear for two weeks for a much needed vacation, but I'll be interested to see other folks comments/opinions on this when I get back.

Dave

Signature · 5 lines

http://www.codemonkey.org.uk
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 5 lines · David Singleton

If I had all the existing cpufreq tables transformed into operating points I could make a patch that would remove the bulk of cpufreq code from the kernel and you'd have pretty much the same functionality without the maintenance issues the added layers and complexity bring.

If this is going to fly at all, I think thats where we need to be headed. Having two parts of the kernel doing the same thing just seems very wrong to me.

The other alternative as suggested earlier this week would be archictures getting to 'opt out' of powerop for their cpufreq drivers where it doesn't necessarily bring anything but the layer of indirection.

I'm about to disappear for two weeks for a much needed vacation, but I'll be interested to see other folks comments/opinions on this when I get back.

Dave

--
http://www.codemonkey.org.uk

Quoted 7 lines

The other alternative as suggested earlier this week would be archictures getting to 'opt out' of powerop for their cpufreq drivers where it doesn't necessarily bring anything but the layer of indirection.

I'm about to disappear for two weeks for a much needed vacation, but I'll be interested to see other folks comments/opinions on this when I get back.

This week I got some really good feedback and suggestions from Mark Gross on the kernel interface and usability and I have two new additions for this patch set. So I spend the week working on a well thought out kernel interface.

1) I believe I now have the right kernel interface for a common power management infrastructure.

The new kernel interface still uses /sys/power/state to both show the current operating point and set a desired operating 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

/sys/power/operating_points/high/frequency /sys/power/operating_points/high/voltage /sys/power/operating_points/high/latency

I've finally had a bit of time to get the sysfs one file - one value system in place for OpPoint.

2) The really good news is there is a now a power manager for
OpPoint now,
both in rpm and src rpm form. And since the new power manager runs off the new kernel interface and actually does what the cpuspeed daemon does I think the kernel interface is sound.

I took the cpuspeed power manager daemon, version 1.2.1, and modified it Friday to use the oppoint interface. It supports all the options the cpuspeed daemon does, (and can actually still be compiled to be the original cpuspeed daemon) it just uses the interface described above instead of the cpufreq interfaces.

Hi!

Quoted 22 lines

Quoted 7 lines

The other alternative as suggested earlier this week would be archictures getting to 'opt out' of powerop for their cpufreq drivers where it doesn't necessarily bring anything but the layer of indirection.

I'm about to disappear for two weeks for a much needed vacation, but I'll be interested to see other folks comments/opinions on this when I get back.

This week I got some really good feedback and suggestions from Mark Gross on the kernel interface and usability and I have two new additions for this patch set. So I spend the week working on a well thought out kernel interface.

1) I believe I now have the right kernel interface for a common power management infrastructure.

The new kernel interface still uses /sys/power/state to both show the current operating point and set a desired operating 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:

Quoted 7 lines

/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?

And '600MHz' makes lot more sense than 'lowest' on centrino.

Quoted 4 lines

/sys/power/operating_points/high/frequency /sys/power/operating_points/high/voltage /sys/power/operating_points/high/latency

What is voltage for 'mem'?

Quoted 10 lines

I've finally had a bit of time to get the sysfs one file - one value system in place for OpPoint.

2) The really good news is there is a now a power manager for
OpPoint now,
both in rpm and src rpm form. And since the new power manager runs off the new kernel interface and actually does what the cpuspeed daemon does I think the kernel interface is sound.

Quoted 5 lines

I took the cpuspeed power manager daemon, version 1.2.1, and modified it Friday to use the oppoint interface. It supports all the options the cpuspeed daemon does, (and can actually still be compiled to be the original cpuspeed daemon) it just uses the interface described above instead of the cpufreq interfaces.

Congratulations, you now have inferior version of cpufreq ondemand governor.

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

Quoted 14 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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

Quoted 3 lines

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.

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.

Quoted 2 lines

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.

Quoted 6 lines

Quoted 4 lines

/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.

From: [email protected] [mailto:[email protected]] On Behalf Of Pavel Machek
Sent: Tuesday, August 29, 2006 11:35 AM
To: David Singleton
Cc: [email protected]
Subject: Re: [linux-pm] So, what's the status on the recent patches here?

Hi!

Quoted 14 lines

Quoted 14 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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

Quoted 1 line

Quoted 1 line

What makes you think that mixing operating and sleep

states is good

Quoted 3 lines

Quoted 1 line

idea?

They are all power states managed by the kernel and in the

operating

Quoted 1 line

point concept they are all operating points the system supports.

That does not make mixing them right.

Quoted 2 lines

The system can be set to any of the supported states by

setting their

Quoted 2 lines

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'.

Quoted 4 lines

Quoted 2 lines

And '600MHz' makes lot more sense than 'lowest' on centrino.

Perhaps, but the common name space makes it easy for the

power manager

Quoted 1 line

daemon to perform the same functions without having to know

that the

Quoted 1 line

lowest speed on my laptop is 600Mhz.

And enumerate english strings in power daemon? Limiting the numver of states?

Quoted 11 lines

Quoted 7 lines

Quoted 5 lines

/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

Quoted 1 line

for transistion to that state. I didn't have the data

available when

Quoted 1 line

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.

Quoted 32 lines

From: [email protected] [mailto:[email protected]] On Behalf Of Pavel Machek
Sent: Tuesday, August 29, 2006 11:35 AM
To: David Singleton
Cc: [email protected]
Subject: Re: [linux-pm] So, what's the status on the recent patches here?

Hi!

Quoted 14 lines

Quoted 14 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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

Quoted 1 line

Quoted 1 line

What makes you think that mixing operating and sleep

states is good

Quoted 3 lines

Quoted 1 line

idea?

They are all power states managed by the kernel and in the

operating

Quoted 1 line

point concept they are all operating points the system supports.

Quoted 1 line

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?

---

Quoted 8 lines

Quoted 2 lines

The system can be set to any of the supported states by

setting their

Quoted 2 lines

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'.

---

So, why don't you think this simplification is possible?

---

Quoted 11 lines

Quoted 4 lines

Quoted 2 lines

And '600MHz' makes lot more sense than 'lowest' on centrino.

Perhaps, but the common name space makes it easy for the

power manager

Quoted 1 line

daemon to perform the same functions without having to know

that the

Quoted 1 line

lowest speed on my laptop is 600Mhz.

And enumerate english strings in power daemon? Limiting the numver of states?

---

Are you saying that on your laptop, all possible CPU and bus frequencies

can be used independently? So, it would be unnecessarily limiting to have
the system designer provide a list of combinations that work? Remember that
the scope of this is a limited set of parameters, not all the devices in
the system.

---

Quoted 12 lines

Quoted 11 lines

Quoted 7 lines

Quoted 5 lines

/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

Quoted 8 lines

Quoted 1 line

for transistion to that state. I didn't have the data

available when

Quoted 1 line

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.

---

Why isn't 0 a meaningful value for frequency? And I can imagine that some hardware might have different voltage options for sleep States. Additionally, these sys entries could represent the frequency, voltage, etc., that the system would go to upon resuming from sleep...

scott

_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

From: Matthew Locke [mailto:[email protected]]
...

Quoted 4 lines

Could you say why you think [frequencies and sleep states] 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. The per

point transition callbacks are needed just to handle the sleep points.
Latency has a very different meaning between the two types. Also, the type field is required to identify which points are sleep points and which ones are operating points. I think the concept of using operating points to define sleep states could be a valid one but the implementation provided isn't quite right (yet).

...

I think its more an issue with the implementation rather than the concept. We can't just have frequency and voltage as shown in oppoint patches because we don't know which frequency and voltage they refer to. The number of frequency and voltage parameters are completely dependent on the hardware platform.

You bring up a more interesting area to look at integrating sleep states and operating points. Can we add some hooks that allow us to define which operating point is selected at resume? Need to think about that a bit:)

Quoted 4 lines

You bring up a more interesting area to look at integrating sleep states and operating points. Can we add some hooks that allow us to define which operating point is selected at resume? Need to think about that a bit:)

---

It's an interesting question, and one we (Motorola) don't have hard data to support, yet. Our current implementation remembers the OP in use before sleeping and resumes at the same OP. The argument is that this corresponds to an application that is doing work at a steady-state level (say decoding video), but that has a brief pause to wait for I/O or a timer (say, pausing until the next frame time); then it makes sense that the level of effort required on resume will be the same as before sleeping.

From: Pavel Machek [mailto:[email protected]]

Quoted 2 lines

It's an interesting question, and one we (Motorola) don't have hard data to support, yet. Our current implementation remembers

the OP in

Quoted 1 line

use before sleeping and resumes at the same OP. The

argument is that

Quoted 2 lines

this corresponds to an application that is doing work at a steady-state level (say decoding video), but that has a

brief pause to

Quoted 1 line

wait for I/O or a timer (say, pausing until the next frame

time); then

Quoted 1 line

it makes sense that the level of effort required on resume

will be the

Quoted 1 line

same as before sleeping.

We may have confusion here.

On PC, it is definitely not possible to enter sleep state between frames of video... because video is powered off.

On PC, sleep states are *system* sleep states. CPU sleep states exist, too, but that's in-kernel implementation detail. They are called C1..C4.

Quoted 8 lines

We may have confusion here.

On PC, it is definitely not possible to enter sleep state between frames of video... because video is powered off.

On PC, sleep states are *system* sleep states. CPU sleep states exist, too, but that's in-kernel implementation detail. They are called C1..C4.

---

Well, we have some hardware where we can sleep everything but memory and some where we can also leave the display active (and backlit). In fact, however, today the latency for going to sleep is too great to do so between frames, so we just do a wait there. We would LIKE to be able to sleep there at some point in the future and would prefer a power model that made that cleanly part of a continuum of operating points.

However, we definitely DO sleep (with self-refreshing RAM) during relatively short periods, with the wakeup resulting from an interrupt from the RTC (which is self-powered and is set to timeout at the next scheduled timer when we go to sleep) or another hardware interrupt. We think of this as a system-level sleep state.

I'm not sure how you distinguish between a "system" sleep state and a "CPU" sleep state - seems like there's a collection of things that can be shut down or not; except for true OFF, there's always something on.

Quoted 32 lines · Preece Scott-PREECE

Quoted 32 lines

From: [email protected] [mailto:[email protected]] On Behalf Of Pavel Machek
Sent: Tuesday, August 29, 2006 11:35 AM
To: David Singleton
Cc: [email protected]
Subject: Re: [linux-pm] So, what's the status on the recent patches here?

Hi!

Quoted 14 lines

Quoted 14 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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

Quoted 1 line

Quoted 1 line

What makes you think that mixing operating and sleep

states is good

Quoted 3 lines

Quoted 1 line

idea?

They are all power states managed by the kernel and in the

operating

Quoted 1 line

point concept they are all operating points the system supports.

Quoted 7 lines

Quoted 1 line

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.

The per point
transition callbacks are needed just to handle the sleep points.

Latency has a very different meaning between the two types.

Also, the
type field is required to identify which points are sleep points and which ones are operating points.

I think the concept of using
operating points to define sleep states could be a valid one but the implementation provided isn't quite right (yet).

However, this should not detract from mainlining PowerOP. Integrating sleep and operating points is not required to use PowerOP.

Quoted 60 lines

---

Quoted 8 lines

Quoted 2 lines

The system can be set to any of the supported states by

setting their

Quoted 2 lines

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'.

---

So, why don't you think this simplification is possible?

---

Quoted 11 lines

Quoted 4 lines

Quoted 2 lines

And '600MHz' makes lot more sense than 'lowest' on centrino.

Perhaps, but the common name space makes it easy for the

power manager

Quoted 1 line

daemon to perform the same functions without having to know

that the

Quoted 1 line

lowest speed on my laptop is 600Mhz.

And enumerate english strings in power daemon? Limiting the numver of states?

---

Are you saying that on your laptop, all possible CPU and bus frequencies

can be used independently? So, it would be unnecessarily limiting to have
the system designer provide a list of combinations that work? Remember that
the scope of this is a limited set of parameters, not all the devices in
the system.

---

Quoted 12 lines

Quoted 11 lines

Quoted 7 lines

Quoted 5 lines

/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

Quoted 8 lines

Quoted 1 line

for transistion to that state. I didn't have the data

available when

Quoted 1 line

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.

Quoted 6 lines

---

Why isn't 0 a meaningful value for frequency? And I can imagine that some hardware might have different voltage options for sleep States. Additionally, these sys entries could represent the frequency, voltage, etc., that the system would go to upon resuming from sleep...

I think its more an issue with the implementation rather than the concept. We can't just have frequency and voltage as shown in oppoint patches because we don't know which frequency and voltage they refer to. The number of frequency and voltage parameters are completely dependent on the hardware platform.

You bring up a more interesting area to look at integrating sleep states and operating points. Can we add some hooks that allow us to define which operating point is selected at resume? Need to think about that a bit:)

Quoted 8 lines

scott

_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Quoted 43 lines · Matthew Locke

Quoted 32 lines · Preece Scott-PREECE

Quoted 32 lines

From: [email protected] [mailto:[email protected]] On Behalf Of Pavel Machek
Sent: Tuesday, August 29, 2006 11:35 AM
To: David Singleton
Cc: [email protected]
Subject: Re: [linux-pm] So, what's the status on the recent patches here?

Hi!

Quoted 14 lines

Quoted 14 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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

Quoted 1 line

Quoted 1 line

What makes you think that mixing operating and sleep

states is good

Quoted 3 lines

Quoted 1 line

idea?

They are all power states managed by the kernel and in the

operating

Quoted 1 line

point concept they are all operating points the system supports.

Quoted 7 lines

Quoted 1 line

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?

Quoted 7 lines

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.

Quoted 52 lines · David Singleton

Quoted 43 lines · Matthew Locke

Quoted 32 lines · Preece Scott-PREECE

Quoted 32 lines

From: [email protected] [mailto:[email protected]] On Behalf Of Pavel Machek
Sent: Tuesday, August 29, 2006 11:35 AM
To: David Singleton
Cc: [email protected]
Subject: Re: [linux-pm] So, what's the status on the recent patches here?

Hi!

Quoted 14 lines

Quoted 14 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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

Quoted 1 line

Quoted 1 line

What makes you think that mixing operating and sleep

states is good

Quoted 3 lines

Quoted 1 line

idea?

They are all power states managed by the kernel and in the

operating

Quoted 1 line

point concept they are all operating points the system supports.

Quoted 7 lines

Quoted 1 line

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?

Quoted 7 lines

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.

Quoted 4 lines

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.

Greetings,
Rafael

--
You never change things by fighting the existing reality.
R. Buckminster Fuller

Quoted 58 lines · Rafael J. Wysocki

Quoted 52 lines · David Singleton

Quoted 43 lines · Matthew Locke

Quoted 32 lines · Preece Scott-PREECE

Quoted 32 lines

From: [email protected] [mailto:[email protected]] On Behalf Of Pavel Machek
Sent: Tuesday, August 29, 2006 11:35 AM
To: David Singleton
Cc: [email protected]
Subject: Re: [linux-pm] So, what's the status on the recent patches here?

Hi!

Quoted 14 lines

Quoted 14 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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

Quoted 1 line

Quoted 1 line

What makes you think that mixing operating and sleep

states is good

Quoted 3 lines

Quoted 1 line

idea?

They are all power states managed by the kernel and in the

operating

Quoted 1 line

point concept they are all operating points the system supports.

Quoted 7 lines

Quoted 1 line

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?

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 10 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

No, processes are not frozen for simple cpu frequency change -- on non-broken cpus.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

I've been off doing real work for a while but I've finally got some time
to work on SMP and device constraints for the oppoint patch set.

Once I get SMP working well I'm going to spend some time thinking
about suspend operating states. The pm_ops structure looks
suspicioulsy like a subset of the oppoint structure. If I can

Quoted 4 lines · Pavel Machek

Quoted 3 lines

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.

Quoted 2 lines

No, processes are not frozen for simple cpu frequency change -- on non-broken cpus.

I didn't say cpu frequency changes freeze processes. I said a suspend does a prepare to suspend step (which freezes processes) and a cpu frequency change does a prepare to change frequency step (where it will run the driver notifier list to get drivers set to scale).

They both do the same three steps:

1) prepare to transition

2) transition

3) finish transition

That's one of my arguements as to why suspend states should be treated just like frequency states.

Quoted 8 lines · David Singleton

Quoted 6 lines · Pavel Machek

Quoted 3 lines

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.

No, processes are not frozen for simple cpu frequency change -- on non-broken cpus.

Quoted 4 lines

I didn't say cpu frequency changes freeze processes. I said a suspend does a prepare to suspend step (which freezes processes) and a cpu frequency change does a prepare to change frequency step (where it will run the driver notifier list to get drivers set to scale).

Yep, and switching consoles is also same. It is prepare to switch, do a switch, notify people you switched. Shall we use same code?

Quoted 11 lines

They both do the same three steps:

1) prepare to transition

2) transition

3) finish transition

That's one of my arguements as to why suspend states should be treated just like frequency states.

Cat and horse is a same animal. They both have 4 legs, one head and a tail.

Anyway, as a software suspend maintainer, I do not want you to add non-sleeping states to /sys/power/state. I will NAK any attempt to do so. Please find more suitable interface.

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

Quoted 6 lines

Cat and horse is a same animal. They both have 4 legs, one head and a tail.

Anyway, as a software suspend maintainer, I do not want you to add non-sleeping states to /sys/power/state. I will NAK any attempt to do so. Please find more suitable interface.

You are right. The power/state files for devices are for suspend states as well. I'll find a different interface for operating states and leave suspend states in /sys/power/state.

Quoted 17 lines · Pavel Machek

Quoted 8 lines · David Singleton

Quoted 6 lines · Pavel Machek

Quoted 3 lines

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.

No, processes are not frozen for simple cpu frequency change -- on non-broken cpus.

Quoted 7 lines

I didn't say cpu frequency changes freeze processes. I said a suspend
does a prepare to suspend step (which freezes processes) and a cpu frequency
change does a prepare to change frequency step (where it will run the driver
notifier list to get drivers set to scale).

Quoted 2 lines

Yep, and switching consoles is also same. It is prepare to switch, do a switch, notify people you switched. Shall we use same code?

No. Since switching console is not dealing with changing the operating state of the system. It's just switching which device is the console.

Quoted 16 lines

Quoted 5 lines

They both do the same three steps:

1) prepare to transition

Quoted 7 lines

2) transition

3) finish transition

That's one of my arguements as to why suspend states should be treated
just like frequency states.

Cat and horse is a same animal. They both have 4 legs, one head and a tail.

Quoted 3 lines

Anyway, as a software suspend maintainer, I do not want you to add non-sleeping states to /sys/power/state. I will NAK any attempt to do so. Please find more suitable interface.

You are right. The power/state files for devices are for suspend states as well. I'll find a different interface for operating states and
leave suspend states in /sys/power/state.

David

Quoted 5 lines

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

_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

Hi!

Quoted 18 lines

Quoted 17 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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?

Quoted 4 lines

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.

Quoted 5 lines

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'.

Quoted 3 lines

Quoted 2 lines

And '600MHz' makes lot more sense than 'lowest' on centrino.

Quoted 5 lines

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?

Quoted 8 lines

Quoted 7 lines

Quoted 5 lines

/sys/power/operating_points/high/frequency /sys/power/operating_points/high/voltage /sys/power/operating_points/high/latency

What is voltage for 'mem'?

Quoted 7 lines

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.

--
Thanks for all the (sleeping) penguins.

Quoted 24 lines · Pavel Machek

Hi!

Quoted 22 lines

Quoted 14 lines

Quoted 1 line

point, by name. There is a new

/sys/power/operating_points directory

Quoted 1 line

that shows all the operating points the

system supports. An

Quoted 9 lines

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

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 12 lines

Quoted 5 lines

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'.

Quoted 3 lines

Quoted 2 lines

And '600MHz' makes lot more sense than 'lowest' on centrino.

Quoted 8 lines

Quoted 5 lines

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.

Quoted 16 lines

Quoted 8 lines

Quoted 7 lines

Quoted 5 lines

/sys/power/operating_points/high/frequency /sys/power/operating_points/high/voltage /sys/power/operating_points/high/latency

What is voltage for 'mem'?

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

--
Thanks for all the (sleeping) penguins.

_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm

[mailto:[email protected]] On Behalf Of Matthew Locke

Latency is a good example of how mixing sleep states with operating points doesn't quite work. Latency for switching to a new operating
point is very a much a function of the current operating point. I
think latency for sleep states is the same every time. Also which direction are you capturing latency for, suspend or resume? If your power manager is making decisions based on latency, I could imagine that it needs to know the latency for going into and out of that state.

Quoted 9 lines · Pavel Machek

Hi!

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

/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

Quoted 1 line

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.

Quoted 6 lines

Quoted 5 lines

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.

Quoted 2 lines

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.

The patchset and rpmsl are available at:

http://source.mvista.com/~dsingleton

Quoted 4 lines · David Singleton

The patchset and rpmsl are available at:

http://source.mvista.com/~dsingleton

Care to put up a tarball for those of us running on distros that are not RPM based?

thanks,

greg k-h

Quoted 19 lines · David Singleton

Quoted 6 lines

If I had all the existing cpufreq tables transformed into operating points I could make a patch that would remove the bulk of cpufreq code from the kernel and you'd have pretty much the same functionality without the maintenance issues the added layers and complexity bring.

If this is going to fly at all, I think thats where we need to be headed. Having two parts of the kernel doing the same thing just seems very wrong to me.

The other alternative as suggested earlier this week would be archictures getting to 'opt out' of powerop for their cpufreq drivers where it doesn't necessarily bring anything but the layer of indirection.

I'm about to disappear for two weeks for a much needed vacation, but I'll be interested to see other folks comments/opinions on this when I get back.

1) I believe I now have the right kernel interface for a common power management infrastructure.

2006/8/26, David Singleton <[email protected]>:

Quoted 2 lines · Dave Jones

Quoted 1 line · David Singleton

Quoted 2 lines

1) I believe I now have the right kernel interface for a common power management infrastructure.

- md_data has an issue from OO design paradigm perspective. OpPoint requires an entity above PowerOP to know internals of arch md_data (see centrino-dynamic-powerop.c implementation) and thus requires an arch

Hi!

Okay, I never liked opPoint framework... so your critism seems okay, but do your patches really solve all the points you raised?

Quoted 3 lines

2006/8/26, David Singleton <[email protected]>:

Quoted 2 lines · Dave Jones

Quoted 1 line · David Singleton

...

Quoted 6 lines

Quoted 2 lines

1) I believe I now have the right kernel interface for a common power management infrastructure.

- md_data has an issue from OO design paradigm perspective. OpPoint requires an entity above PowerOP to know internals of arch md_data (see centrino-dynamic-powerop.c implementation) and thus requires an arch

Is that what you were trying to solve with string parsing?

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2006/8/26, David Singleton <[email protected]>:

Quoted 21 lines · Dave Jones

Quoted 19 lines · David Singleton

Quoted 6 lines

If I had all the existing cpufreq tables transformed into operating points I could make a patch that would remove the bulk of cpufreq code from the kernel and you'd have pretty much the same functionality without the maintenance issues the added layers and complexity bring.

If this is going to fly at all, I think thats where we need to be headed. Having two parts of the kernel doing the same thing just seems very wrong to me.

The other alternative as suggested earlier this week would be archictures getting to 'opt out' of powerop for their cpufreq drivers where it doesn't necessarily bring anything but the layer of indirection.

I'm about to disappear for two weeks for a much needed vacation, but I'll be interested to see other folks comments/opinions on this when I get back.

[snip]

Quoted 3 lines

1) I believe I now have the right kernel interface for a common power management infrastructure.

OpPoint continues to focus on user space interface development for power management in contrast to that there seem to be an agreemment in the comunity to defer this integration due to in fact quite a lot of open/undiscussed and complex questions about this integration and instead to focus on getting a consensus on operating point structure definition and methods to work with the structure instances.

OpPoint continues to focus on integration with CPUFreq in a manner which was outlined as an anacceptable during recent discussions on the list - removing the concept of a inkernel governor and most of the CPUFreq feature code.

OpPoint continues to develop userspace interfaces and integration based on operating point definition for which Matt and I posted issues/questions several time and the posts have been left without a reply.

Below I'm trying to summurize all issues I see with OpPoint approach sometimes using terms defined in PowerOP approach (for example layer names).

'struct powerop' definition
------------------------------------
- frequency, voltage fields are arch specific: not to mention any complex embedded case but current definition and OpPoint implementation does not work even for x86 SMP case.

- latency is not an attribute of a certain operating point but a function of two arguments - current operating point and a point we are goint to switch to. Therefor latency just does not belong to 'struct powerop'

- all hooks are redundant: the hooks are the same for all operating points untill we come to the integration with suspend/resume. But we believe the intagration needs more investigation at the first place and at the second we feel like the integration may be handled on PM Core layer instead of having per operating point hooks

- prepare_transition and finish_ransition may be moved even below PM Core to clock/voltage framework; needs more carefull investigation though

- md_data has an issue from OO design paradigm perspective. OpPoint requires an entity above PowerOP to know internals of arch md_data (see centrino-dynamic-powerop.c implementation) and thus requires an arch dependent header file to be included in the code which can be impemented in arch independent manner. That would be fine if there was no solution to achieve required functionality without such a hack but PowerOP provides such approach by dereferencing power parameters by name. File which implements operating points registration in PowerOP approach does not include any header file from include/asm-* subtrees.

All further pieces porposed by OpPOint base on the above incorrect design of the main structure and therefore have issues.

integration with suspend/resume
-------------------------------
- mixing system state and operating point concept (different points may correspond to a sleep/standby system state)

- legacy PM states are redefined via new OpPOint interface but do not use it (explicit 'if' statements in legacy pm code instead of OpPOint hooks uilization)

- names for operating points presented in the original letter below implicitly assumed the points are ranged by some order (now it is from the highest [power comsumption] to the lowest. However having many more power parameters than just one freq and one voltage does not allow to range the points in such a way and a string name without knowledge of a particular power parameter values is not sufficient

(even in x86 SMP case: not to mention it's hard to me to express SMP case in current OpPOint terms but what are names and how to distinguish/range 2 CPUs system states corresponded to 'highest point for CPU0 + medium for CPU1' against 'low for CPU0 + high for CPU1' ?)

- no example of (at least optional) capability to export information about particular power paramenter is presented while it was obviously highlighted by embedded community that it is a must

- direct utilization of PM internal structure 'pm_state' instead of an attempt of an API

cpufreq core and a cpufreq driver/OpPOint integration
-------------------------------
- integration with legacy cpufreq interface is completely missing in both arch (x86 and pxa) examples. If OpOint was a universal approach it would allow to build different interfaces on top of it. In this case you can porpose more optimized/improved interface if you feel existed interface has issues leaving existed interface as a [configurable] option and remove it when agreed.

- while clear desgin and interfaces are outlined for so called PM Core layer by PowerOP approach this layer is not addressed by OpPoints in any way

- a cpufreq driver still should contains code to access arch hardware while the functionality of cpufreq driver falls into PM Core layer and there is no longer reason to have the functionality related to cpufreq concept

- no any integration with clock/voltage framework. Integral solution which includes Clock/voltage framework just saves more power [period].

x86 cpufreq/OpPoint integration
-------------------------------
- struct powerop hooks are expected to be arch specific but intialized by some cpufreq core routines

- cpufreq driver still shares cpufreq core cpufreq_frequncy_table structure

- integration with legacy cpufreq interface is completely missing

- OpPoint design does not handle SMP case.

PowerOP addresses all the issues mentioned above and works for SMP case. Integration with legacy kernel PM code (including constraints and standalone driver suspend/resume) and a certain userspace interface (basically which can be any having current PowerOP interface underneath) are the next steps for PowerOP approach once the correct brick of PowerOP layer is in place.

Eugeny

Quoted 26 lines

2006/8/26, David Singleton <[email protected]>:

Quoted 21 lines · Dave Jones

Quoted 19 lines · David Singleton

Quoted 6 lines

If I had all the existing cpufreq tables transformed into operating points I could make a patch that would remove the bulk of cpufreq code from the kernel and you'd have pretty much the same functionality without the maintenance issues the added layers and complexity bring.

If this is going to fly at all, I think thats where we need to be headed. Having two parts of the kernel doing the same thing just seems very wrong to me.

The other alternative as suggested earlier this week would be archictures getting to 'opt out' of powerop for their cpufreq drivers where it doesn't necessarily bring anything but the layer of indirection.

I'm about to disappear for two weeks for a much needed vacation, but I'll be interested to see other folks comments/opinions on this when I get back.

[snip]

Quoted 3 lines

1) I believe I now have the right kernel interface for a common power management infrastructure.

Quoted 6 lines

OpPoint continues to focus on user space interface development for power management in contrast to that there seem to be an agreemment in the comunity to defer this integration due to in fact quite a lot of open/undiscussed and complex questions about this integration and instead to focus on getting a consensus on operating point structure definition and methods to work with the structure instances.

Actually OpPoint is focusing on all the interfaces, user-kernel, kernel-architecture
independent - power management interfaces, and power management framework -
architecture/platform specific interfaces.

Quoted 6 lines

OpPoint continues to focus on integration with CPUFreq in a manner which was outlined as an anacceptable during recent discussions on the list - removing the concept of a inkernel governor and most of the CPUFreq feature code.

The point of OpPoint is to show that a unified power management infrastructure is possible and that bolting on another power management infrastructure to the kernel is not the right approach.

OpPoint is not trying to replace cpufreq. It's trying to unify all the power management
infrastructures into a a single infrastructure. OpPoint uses the cpufreq notifier
infrastructure to do both operating opoint transition and driver scaling notification,
and it performs the same basic functions as cpufreq, without the policy and governor
code. It is also performing all the same Dynamic Power Management functionality on the pxa27x mainstone. The point is one infrastructure can support them.

And with the new oppointd power daemon it is performing all the same functions as cpuspeed did on my laptop, just with a lot less code in the kernel.

Quoted 7 lines

OpPoint continues to develop userspace interfaces and integration based on operating point definition for which Matt and I posted issues/questions several time and the posts have been left without a reply.

Sorry, I'm having a hard time keeping up with all the email threads.

Quoted 5 lines

Below I'm trying to summurize all issues I see with OpPoint approach sometimes using terms defined in PowerOP approach (for example layer names).

Quoted 5 lines

'struct powerop' definition
------------------------------------
- frequency, voltage fields are arch specific: not to mention any complex embedded case but current definition and OpPoint implementation does not work even for x86 SMP case.

Actually frequency, voltage and latency fields are architecture independent and a necessary peice of information that any power manager must have.

You are right, I have not yet put in the additional layer to support SMP systems. That is one of the pieces I'm still working on.

Quoted 4 lines

- latency is not an attribute of a certain operating point but a function of two arguments - current operating point and a point we are goint to switch to. Therefor latency just does not belong to 'struct powerop'

I disagree.

Quoted 7 lines

- all hooks are redundant: the hooks are the same for all operating points untill we come to the integration with suspend/resume. But we believe the intagration needs more investigation at the first place and at the second we feel like the integration may be handled on PM Core layer instead of having per operating point hooks

The hooks are not redundant nor the same for all operating points. Each operating point defines it's prepare, transition, and finish functions for the hooks. And different types of operating points may have completely different functions in those hooks, on the same platform.

Quoted 3 lines

- prepare_transition and finish_ransition may be moved even below PM Core to clock/voltage framework; needs more carefull investigation though

I disagree. Both the pm suspend and cpufreq code has them in exactly the same place.

Quoted 11 lines

- md_data has an issue from OO design paradigm perspective. OpPoint requires an entity above PowerOP to know internals of arch md_data (see centrino-dynamic-powerop.c implementation) and thus requires an arch dependent header file to be included in the code which can be impemented in arch independent manner. That would be fine if there was no solution to achieve required functionality without such a hack but PowerOP provides such approach by dereferencing power parameters by name. File which implements operating points registration in PowerOP approach does not include any header file from include/asm-* subtrees.

No, the md_data is the opaque pointer into architecture dependent data. The power management infrastructure doens't need to know what data is linked into md_data, just as drivers have driver specific structs that are opaque to the upper layers of software.

Quoted 4 lines

All further pieces porposed by OpPOint base on the above incorrect design of the main structure and therefore have issues.

wow.

Quoted 5 lines

integration with suspend/resume
-------------------------------
- mixing system state and operating point concept (different points may correspond to a sleep/standby system state)

The pxa27x code shows that indeed there are more than one suspsend state, which is why the operating point model works so well on both my centrino laptop and my pxa27x mainstone running the same oppointd power daemon.

Quoted 4 lines

- legacy PM states are redefined via new OpPOint interface but do not use it (explicit 'if' statements in legacy pm code instead of OpPOint hooks uilization)

The enter_state code could be merged into the pm_change code, or vice versa, I haven't had time to make it really unified and pretty.

Quoted 7 lines

- names for operating points presented in the original letter below implicitly assumed the points are ranged by some order (now it is from the highest [power comsumption] to the lowest. However having many more power parameters than just one freq and one voltage does not allow to range the points in such a way and a string name without knowledge of a particular power parameter values is not sufficient

That's not quite correct. The ordering of names, lowest to highest, allows the power manager daemon to cover most of the use cases right out of the box. It's performing the same functions on both my centrino laptop and the pxa27x mainstone right now without any changes to either the power manager or power managenment config file.

One of the next boards I'm working on has different operating points at the same frequency, but different voltages. All that is realy required to support this a plugin to the power manager that understand the different operating points so it can best choose when to transition to each point.

Custom plugins to a power manager that lets the power manager deal with the unique set of operating points on a particular platform is one of the really attractive parts of OpPoint. It won't have to be woven into the kernel.

Quoted 4 lines

(even in x86 SMP case: not to mention it's hard to me to express SMP case in current OpPOint terms but what are names and how to distinguish/range 2 CPUs system states corresponded to 'highest point for CPU0 + medium for CPU1' against 'low for CPU0 + high for CPU1' ?)

I'm still working on the SMP case. It's not that I'm ignoring it. Give me a few more days.

Quoted 1 line

Quoted 3 lines

- no example of (at least optional) capability to export information about particular power paramenter is presented while it was obviously highlighted by embedded community that it is a must

Which parameters besides frequency, voltage and latency are required to be exported to the power manager?

Quoted 4 lines

- direct utilization of PM internal structure 'pm_state' instead of an attempt of an API

Quoted 8 lines

cpufreq core and a cpufreq driver/OpPOint integration
-------------------------------
- integration with legacy cpufreq interface is completely missing in both arch (x86 and pxa) examples. If OpOint was a universal approach it would allow to build different interfaces on top of it. In this case you can porpose more optimized/improved interface if you feel existed interface has issues leaving existed interface as a [configurable] option and remove it when agreed.

I'm sorry, I don't understand that statement. I'm still opposed to dynamic-on-the-fly construction of operating points. It's really dangerous. The hardware vendors want it so that new hardware doesn't have to wait for software before they can sell it.

The cpufreq structure of defining and validating operating points before being integrated into the kernel is the correct way to do it, in my opinion.

Quoted 2 lines

- OpPoint design does not handle SMP case.

Quoted 7 lines

PowerOP addresses all the issues mentioned above and works for SMP case. Integration with legacy kernel PM code (including constraints and standalone driver suspend/resume) and a certain userspace interface (basically which can be any having current PowerOP interface underneath) are the next steps for PowerOP approach once the correct brick of PowerOP layer is in place.

It does?

David

Quoted 3 lines

Eugeny

Quoted 2 lines

- latency is not an attribute of a certain operating point but a

function of

Quoted 2 lines

two arguments - current operating point and a point we are goint to switch to. Therefor latency just does not belong to 'struct powerop'

I disagree.

[mailto:[email protected]] On Behalf Of Amit Kucheria

Quoted 4 lines

Quoted 2 lines

- latency is not an attribute of a certain operating point but a

function of

Quoted 1 line

two arguments - current operating point and a point we

are goint to

Quoted 1 line

Quoted 1 line

switch to. Therefor latency just does not belong to

'struct powerop'

Quoted 2 lines

I disagree.

Problem is that you disagree without giving your reasons. Here is another reason putting latency into your operating point definition isn't going to fly:

http://lwn.net/Articles/196900/ <--- An API for specifying latency constraints

http://lwn.net/Articles/197282/

Quoted 12 lines

[mailto:[email protected]] On Behalf Of Amit Kucheria

Quoted 4 lines

Quoted 2 lines

- latency is not an attribute of a certain operating point but a

function of

Quoted 1 line

two arguments - current operating point and a point we

are goint to

Quoted 1 line

Quoted 1 line

switch to. Therefor latency just does not belong to

'struct powerop'

Quoted 2 lines

I disagree.

Quoted 8 lines

Problem is that you disagree without giving your reasons. Here is another reason putting latency into your operating point definition isn't going to fly:

http://lwn.net/Articles/196900/ <--- An API for specifying latency constraints

http://lwn.net/Articles/197282/

---

So, if a driver had set acceptable_latency to 300ms, the Power-Management policy manager could look at the range of available Ops and pick the lowest-power OP that met the expected load and would also meet the required latency guarantee. [And note that the acceptable latency has to include both the resume time and whatever part of suspend happens with interrupts blocked and can't be aborted.]

I like this new facility a lot. Now we just need something similar for expressing anticipated required processing capacity ("I need n thousand instructions executed in the next s seconds") in a nice platform-independent way...