cpuset configuration and measurements for power management

Mike Turquette mturquette at linaro.org
Tue Aug 23 18:13:43 UTC 2011


On Tue, Aug 23, 2011 at 6:07 AM, Vincent Guittot
<vincent.guittot at linaro.org> wrote:
> On 23 August 2011 14:41, Daniel Lezcano <daniel.lezcano at 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-----
>>
>



More information about the linaro-dev mailing list