On Tue, Aug 23, 2011 at 6:07 AM, Vincent Guittot vincent.guittot@linaro.org wrote:

On 23 August 2011 14:41, Daniel Lezcano daniel.lezcano@linaro.org wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi all,

I did the following cpuset configuration:

if [ ! -d /sys/fs/cgroup ]; then        echo "cgroup not supported by the kernel" else        mount -t cgroup cgroup /sys/fs/cgroup

# needed to have the cgroup values inherited from        # the parent cgroup        echo 1 > /sys/fs/cgroup/cgroup.clone_children

# create an empty cgroup 'cpu0'        mkdir /sys/fs/cgroup/cpu0

# create an empty cgroup 'cpu1'        mkdir /sys/fs/cgroup/cpu1

# assign cpu number '0' for cgroup cpu0        echo 0 > /sys/fs/cgroup/cpu0/cpuset.cpus

# move outself to this new cgroup        echo $$ > /sys/fs/cgroup/cpu0

# move all the tasks to the cpu0 cgroup        # kernel threads won't be moved, don't worry about the        # the errors.        for i in $(cat /sys/fs/cgroup/tasks); do                echo $i > /sys/fs/cgroup/cpu0/tasks || echo "failed to add pid $i/$(cat /proc/$i/comm)"        done

# assign a cpu for cgroup cpu1        echo 1 > /sys/fs/cgroup/cpu1/cpuset.cpus

# make cpu1 exclusive so processes belonging        # to the other cgroups won't be able to use it.        echo 1 > /sys/fs/cgroup/cpu1/cpuset.cpu_exclusive fi

At this point, most of the processes have been moved to the 'cpu0' cgroup and will use the cpu0 only. That does not prevent the cpu1 to be used by the kernel threads. Any application launched will run on cpu0 only.

After running 10 infinite loops, the cpu accounting gives:

cat /sys/fs/cgroup/cpu0/cpuacct.usage_percpu 418943579549 0

cat /sys/fs/cgroup/cpu1/cpuacct.usage_percpu 0 0

But the system is:

cat /sys/fs/cgroup/cpuacct.usage_percpu 456741213041 30734572583

You should get the values before and after your tests and compute the difference. You should also read value of  /sys/fs/cgroup/ level where we still have kernel threads if i have understand your comments

...

My guess is that reflects the kernel booted with the two cpus before we created the cgroup. I am investigation the 'isolcpus' kernel parameter.

I think it is a good starting point to do some consumption measurements.

Mike, Vincent, what do you think ? Do you need more informations or anything else ?

Yes it's a good starting point. One key point will be to be sure to not use cpu1. In fact, we mainly have 2 power efficient states:  use equally the 2 cpus or use only one cpu and put the other one in a low power state.

This is true. I did some rough power measurements last week using an almost identical method to Daniel's and for a typical MP3 playback (display off, no UI) I saw very little improvement on current draw from the battery versus the same test without cpuset trickery.

I think Daniel's stuff is a great start and many many more measurements must be done to get anywhere conclusive, but reducing auxillary CPU wake-ups is critical to getting this method to work.

Regards, Mike

Vincent

...

Thanks  -- Daniel

---

http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOU6AVAAoJEAKBbMCpUGYAbQoH/0NeKLecIuMT57B/w1Jid/bn yzqD3zwMt0EfUwfsU6H5dAYgumMzKmWWXR9+7FvYhkcckXfzumiMLFKhIybrUSz/ LW7ymHwxXcHWqBTKwMCasHzo9WhlRTlLA1pGAqo0qtG1IBpalE68ZRwItdY/HSOw 0mDGoegq4DHQtcF64XwGRZJo2wAsamtlWGejFdqLQU4FONyYI42rLXMNAG6VD3vG CJrIudH5hLz3ZBdHYeRB6kWaj1O4skAW6fgySASiqFWoEaZzvT/7UuVBEYawpuyT Pm+U9OHAfHUWfnyDASFfx6ZQKRS5Uk40XzThjGgwoo598EN8FXZD3N6UZ1WmL2U= =H00Z -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 08/26/2011 04:17 PM, Daniel Lezcano wrote:

Hi all,

I created a wiki page describing what we are trying to achieve with the cpuset for power management.

https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Cpuset

FYI, some people would be interested to use the cpuset and irq affinity to reach the same goal.

http://www.spinics.net/lists/linux-rt-users/msg06530.html

-- Daniel

- -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog

Hello,

On the topic of C-state statistics:

For 11.09 there are BP:s to A) fix powertop for ARM and B) create an Android app for running powertop in Android. By that I mean executing a reconfigured but upstreamable powertop as a service and control it from the app.

I'd like input on usage patterns for powertop from all you PM experts in order to design that app as useful as possible. I'd imagine that the actual display (ncurses-based on other platforms) is cute and sure we should have it, but is it really that useful? Isn't the most important thing to get statistics between a starting and an ending time while some test or use case is executed?

So I am thinking that prio 1 is "tap to start/stop logging" and saving the set of result vectors for each measurement cycle to a file that can be taken out and processed off-line into a diagram or whatever.

Other ideas?

/Tony

On 30 August 2011 10:09, Daniel Lezcano daniel.lezcano@linaro.org wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

I did some simple cpuidle measurements and updated the wiki page.

https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Cpuset

Let me know what do you think about the result.

Is there a way to get the C-states statistics ?

Mike, you mentioned you did a very similar cpuset configuration but you saw only a small improvement in term of power consumption, right ? Do you have an idea why ?

Thanks  -- Daniel

---

http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOXJqyAAoJEAKBbMCpUGYAHS0H/RTpXf+/tZ4S2MD0ZDBLDdM0 h/aAiNAWU3xhAPnJBtIRt11YWuqlZcRYKALEu0xrgkSLpS46pQLwjF5jtGpkUIqT 8GwbrLfhEyguoFXKRtUvgTwirT8z20XMMQK9ScgSqITuZcwI/0NUXDyWrSqqlBKC EG65ihobv9eYEzb0voyohRCwALi9AQoxZOLWrDHGYY6GY5k2RsuUwzGEROkhnfrI OWZyvshib73sK0hHnlwq8LfXsX5RrFwj1kbO4a8+TacUj/co23NNA7QmHfRrLLu0 m9ghodqqyGYueRqGLPWhj/XrbcYac4AqcMTeQGwN7y9Qy+3c11QouYoMUFoD1Eo= =9EC9 -----END PGP SIGNATURE-----

---

linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev

On Tue, Aug 30, 2011 at 11:51 AM, Tony Mansson tony.mansson@linaro.org wrote:

Hello,

On the topic of C-state statistics:

For 11.09 there are BP:s to A) fix powertop for ARM and B) create an Android app for running powertop in Android. By that I mean executing a reconfigured but upstreamable powertop as a service and control it from the app.

I'd like input on usage patterns for powertop from all you PM experts in order to design that app as useful as possible. I'd imagine that the actual display (ncurses-based on other platforms) is cute and sure we should have it, but is it really that useful? Isn't the most

The app in its current state is useful for *users* that might want to see:

- what process causes the most wakeups? - is the system going to lower C-states and P-states?

When it was first released, it caused a huge bunch of fixes to be made across the Linux stack (Gnome & KDE base libraries, apps, kernel), led to timer coalescing, etc. It allowed casual users to know what was going on in the system that was draining their battery so they could complain to developers (app and kernel).

important thing to get statistics between a starting and an ending time while some test or use case is executed?

This requirement is more developer-oriented and an important one too.

So I am thinking that prio 1 is "tap to start/stop logging" and saving the set of result vectors for each measurement cycle to a file that can be taken out and processed off-line into a diagram or whatever.

Yes, but I don't see anything Android-specific in this. PMWG is working with the Validation Team on an energy measurement lab that'd allow us to do something like this across member boards. This could then be integrated into LAVA. So the question then becomes - can the same framework be used on a end-user product e.g. a phone, so we could just supply a .apk to allow control of the device and then run our tests. I think the answer is yes, but I can't commit to a delivery date because the framework itself is a donation from a member and we don't have access to it yet.

Then all we'd need for android is a UI to fire a series of tests and show the end result.

Other ideas?

I'd like to see energy measurement co-relate to system activity using perf/ftrace subsystem so that we can pin-point exactly what is going on at any time during a measurement. That is our medium-term goal - to make it easy for developers to instrument the power profile of their code.

/Amit