sched: cpuacct: Track cpuusage for CPU frequencies
PATCH 1/1 sched: cpuacct: Track cpuusage for CPU frequencies
New file: cpuacct.cpufreq when CONFIG_CPU_FREQ_STATS is enabled.
cpuacct.cpufreq reports the CPU time (nanoseconds) spent at each CPU frequency
Maximum number of frequencies supported is 32. As future architectures are added that support more than 32 frequency levels, CPUFREQ_TABLE_MAX in sched.c needs to be updated.
--- Documentation/cgroups/cpuacct.txt | 3 + kernel/sched.c | 112 +++++++++++++++++++++++++++++++++++++ 2 files changed, 115 insertions(+), 0 deletions(-)
Documentation/cgroups/cpuacct.txt +3 -0
@@ -40,6 +40,9 @@ system: Time spent by tasks of the cgroup in kernel mode. user and system are in USER_HZ unit. +cpuacct.cpufreq file gives the CPU time (in nanoseconds) spent at each CPU +frequency. + cpuacct controller uses percpu_counter interface to collect user and system times. This has two side effects:
kernel/sched.c +112 -0
154 lines not on this page · raw message
Signature · 1 line
1.7.0.1
Quoted 7 lines · On Wednesday 07 April 2010 03:21:59 Mike Chan wrote:
New file: cpuacct.cpufreq when
CONFIG_CPU_FREQ_STATSis enabled.cpuacct.cpufreq reports the CPU time (nanoseconds) spent at each CPU frequency
Maximum number of frequencies supported is 32. As future architectures are added that support more than 32 frequency levels,
CPUFREQ_TABLE_MAXinsched.cneeds to be updated.
Why is accounting of each frequency needed?
pcc-cpufreq driver can do every frequency in a range and supports hundreds of different frequencies, thus it does not depend on CPU_FREQ_TABLE. Would the average frequency be enough to track/account?
This would avoid the static interface of listing each available freq. It would also count "boosted" frequency case which is avail on most recent X86 cpus.
Quoted 5 lines
Signed-off-by Mike Chan <[email protected]>--- Documentation/cgroups/cpuacct.txt | 3 + kernel/sched.c | 112 +++++++++++++++++++++++++++++++++++++ 2 files changed, 115 insertions(+), 0 deletions(-)
...
Quoted 6 lines
static int
cpuacct_populate(struct cgroup_subsys *ss, struct cgroup *cgrp)kernel/sched.c +1
-0@@ -9031,6 +9132,17 @@ static void cpuacct_charge(struct task_struct *tsk, u64 cputime)for (; ca; ca = ca->parent) {u64 *cpuusage =per_cpu_ptr (ca->cpuusage, cpu); +#ifdef CONFIG_CPU_FREQ_STAT
kernel/sched.c static void cpuacct_charge(struct task_struct *tsk, u64 cputime) · line 9145
Quoted 10 lines
kernel/sched.c +10
-0+struct cpufreq_table *cpufreq_table = +per_cpu_ptr (ca->cpufreq_table, cpu); + +if (cpufreq_index >CPUFREQ_TABLE_MAX ) +printk_once (KERN_WARNING "cpuacct_charge: " +"cpufreq_index: %d exceeds max table " +"size\n" , cpufreq_index); +else + cpufreq_table->freq[cpufreq_index] += cputime; +#endif
Can the frequency change somewhere in the middle between cpuacct_charge is called?
What guarantees that the task run at cpufreq_table->freq[cpufreq_index] all the time?
Thomas
Quoted 4 lines
kernel/sched.c +0
-0*cpuusage += cputime; }
2010/4/9 Thomas Renninger <[email protected]>:
Quoted 9 lines · On Wednesday 07 April 2010 03:21:59 Mike Chan wrote:
Quoted 7 lines
New file: cpuacct.cpufreq when
CONFIG_CPU_FREQ_STATSis enabled.cpuacct.cpufreq reports the CPU time (nanoseconds) spent at each CPU frequency
Maximum number of frequencies supported is 32. As future architectures are added that support more than 32 frequency levels,
CPUFREQ_TABLE_MAXinsched.cneeds to be updated.Why is accounting of each frequency needed?
The intent is to track time spent at each cpu frequency to measure power consumption. Userspace can figure out the mapping between frequency and power consumption. This is also a useful indication of what kind of hw performance userspace apps need (does Chrome really need 1ghz?).
Paul Menage had suggested an integral earlier in my [RFC] patch. I wasn't completely against the idea but it had a few shortcomings that I couldn't think of decent solutions for. You would have to either pre-define power consumption for the cpu frequences per-arch or board file. Or have a way to calculate.
Quoted 3 lines
pcc-cpufreq driver can do every frequency in a range and supports hundreds of different frequencies, thus it does not depend on
CPU_FREQ_TABLE. Would the average frequency be enough to track/account?
Humm, this is a tricky case we haven't yet run into for ARM. Average frequency might not be too useful because power is not linear with speed. We could possibly have buckets for speeds (hi/lo).
Quoted 22 lines
This would avoid the static interface of listing each available freq. It would also count "boosted" frequency case which is avail on most recent X86 cpus.
Quoted 5 lines
Signed-off-by Mike Chan <[email protected]>---
Documentation/cgroups/cpuacct.txt | 3 +
kernel/sched.c | 112 +++++++++++++++++++++++++++++++++++++2 files changed, 115 insertions(+), 0 deletions(-)...
Quoted 12 lines
static int
cpuacct_populate(struct cgroup_subsys *ss, struct cgroup *cgrp)kernel/sched.c +7
-0@@ -9031,6 +9132,17 @@ static void cpuacct_charge(struct task_struct *tsk, u64 cputime) for (; ca; ca = ca->parent) { u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu); +#ifdef CONFIG_CPU_FREQ_STAT + struct cpufreq_table *cpufreq_table = + per_cpu_ptr(ca->cpufreq_table, cpu); + + if (cpufreq_index > CPUFREQ_TABLE_MAX) + printk_once(KERN_WARNING "cpuacct_charge: " + "cpufreq_index: %d exceeds max table "
Quoted 9 lines
kernel/sched.c static void cpuacct_charge(struct task_struct *tsk, u64 cputime) · line 9145
Quoted 4 lines
kernel/sched.c +4
-0+ "size\n", cpufreq_index); + else + cpufreq_table->freq[cpufreq_index] += cputime; +#endif Can the frequency change somewhere in the middle between
cpuacct_chargeis called?
What guarantees that the task run at cpufreq_table->freq[cpufreq_index] all the time?
Ah, good catch, it doesn't. What we can do is register a callback for a cpu frequency transition notifier. I can fix this up in a v2.
-- Mike
Quoted 7 lines
Thomas
Quoted 4 lines
kernel/sched.c +0
-1*cpuusage += cputime; } --
Quoted 19 lines · Mike Chan
2010/4/9 Thomas Renninger <[email protected]>:
Quoted 11 lines · On Wednesday 07 April 2010 03:21:59 Mike Chan wrote:
Quoted 8 lines
New file: cpuacct.cpufreq when
CONFIG_CPU_FREQ_STATSis enabled.cpuacct.cpufreq reports the CPU time (nanoseconds) spent at each CPU frequency
Maximum number of frequencies supported is 32. As future architectures are added that support more than 32 frequency levels,
CPUFREQ_TABLE_MAXinsched.cneeds to be updated.Why is accounting of each frequency needed?
The intent is to track time spent at each cpu frequency to measure power consumption. Userspace can figure out the mapping between frequency and power consumption. This is also a useful indication of what kind of hw performance userspace apps need (does Chrome really need 1ghz?).
Quoted 5 lines
Paul Menage had suggested an integral earlier in my [RFC] patch. I wasn't completely against the idea but it had a few shortcomings that I couldn't think of decent solutions for. You would have to either pre-define power consumption for the cpu frequences per-arch or board file. Or have a way to calculate.
Sounds as if this is for specific CPUs/boards only then.
X86 boosting and PCC driver are hard, possibly impossible to track (in respect to real power consumption).
Quoted 6 lines
Quoted 3 lines
pcc-cpufreq driver can do every frequency in a range and supports hundreds of different frequencies, thus it does not depend on
CPU_FREQ_TABLE. Would the average frequency be enough to track/account?Humm, this is a tricky case we haven't yet run into for ARM. Average frequency might not be too useful because power is not linear with speed. We could possibly have buckets for speeds (hi/lo).
Your whole concept sounds as if it requires limited amount of frequencies. Don't mind for the special case I mentioned.
Thomas
Quoted 20 lines · Thomas Renninger
Quoted 19 lines · Mike Chan
2010/4/9 Thomas Renninger <[email protected]>:
Quoted 11 lines · On Wednesday 07 April 2010 03:21:59 Mike Chan wrote:
Quoted 8 lines
New file: cpuacct.cpufreq when
CONFIG_CPU_FREQ_STATSis enabled.cpuacct.cpufreq reports the CPU time (nanoseconds) spent at each CPU frequency
Maximum number of frequencies supported is 32. As future architectures are added that support more than 32 frequency levels,
CPUFREQ_TABLE_MAXinsched.cneeds to be updated.Why is accounting of each frequency needed?
The intent is to track time spent at each cpu frequency to measure power consumption. Userspace can figure out the mapping between frequency and power consumption. This is also a useful indication of what kind of hw performance userspace apps need (does Chrome really need 1ghz?).
Quoted 9 lines
Quoted 5 lines
Paul Menage had suggested an integral earlier in my [RFC] patch. I wasn't completely against the idea but it had a few shortcomings that I couldn't think of decent solutions for. You would have to either pre-define power consumption for the cpu frequences per-arch or board file. Or have a way to calculate.
Sounds as if this is for specific CPUs/boards only then.
X86 boosting and PCC driver are hard, possibly impossible to track (in respect to real power consumption).
Good point, although the class of CPUs that would benefit would be ones with fixed frequencies, very common in the ARM world. For X86 and PPC, if they are not using CONFIG_CPU_FREQ_STAT these statistics will not be enabled. Perhaps what I should really be checking for is CONFIG_CPU_FREQ_TABLE.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
pcc-cpufreq driver can do every frequency in a range and supports hundreds of different frequencies, thus it does not depend on
CPU_FREQ_TABLE. Would the average frequency be enough to track/account?Humm, this is a tricky case we haven't yet run into for ARM. Average frequency might not be too useful because power is not linear with speed. We could possibly have buckets for speeds (hi/lo).
Your whole concept sounds as if it requires limited amount of frequencies. Don't mind for the special case I mentioned.
True, this was mostly inspired by cpufreq stats/time_in_state file, which shows how much time the CPU has spent globally at each frequency.
However applying this to cpu acct groups allows us to track how userspace applications are consuming processing power.
So here are some thoughts after everyone's feedback:
1) Keep tracking in kernel/sched.c: For CPUs that do not use fixed frequencies (PPC, x86), this is disabled, as its too difficult (at least for now) to track. Perhaps later someone with more intelligence than myself and more knowledge of these architectures can figure out a way to track.
2) Add cpuacct notifiers: Introduce cpuacct notifiers that board or mach-cpu files could register. We have the benefit here that at the arch level we know if / how many fixed frequencies we can run at. This is probably going to result in a little bit of code duplication across several architectures, omap, msm and tegra at least for Android.
3) Not useful for upstream. In which case this will go into our android/common branch.
I'm slightly favoring #2. This also gives us the benefit of (optionally) exporting some power integral value Paul Menage suggested earlier, if such power numbers are available from the board-file.
-- Mike
Quoted 2 lines
Thomas