Re: [RFC][PATCH] sched: cpuacct: Track cpuusage per cpu frequency

[Daniel Walker]

On Tue, 2010-04-06 at 12:43 -0700, Mike Chan wrote:
> On Tue, Apr 6, 2010 at 10:48 AM, Daniel Walker <dwalker@xxxxxxxxxx> wrote:
> > On Mon, 2010-04-05 at 12:33 -0700, Mike Chan wrote:
> >> New file: cpuacct.cpufreq when CONFIG_CPU_FREQ_STATS is enabled.
> >>
> >> cpuacct.cpufreq accounts for cpu time per-cpu frequency, time is exported
> >> in nano-seconds
> >>
> >> We do not know the cpufreq table size at compile time.
> >> So a new config option CONFIG_CPUACCT_CPUFREQ_TABLE_MAX is intruduced,
> >> to determine the cpufreq table per-cpu in the cpuacct struct.
> >>
> >> Signed-off-by: Mike Chan <mike@xxxxxxxxxxx>
> >> ---
> >>  init/Kconfig   |    5 +++
> >>  kernel/sched.c |   99 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>  2 files changed, 104 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/init/Kconfig b/init/Kconfig
> >> index eb77e8c..e1e86df 100644
> >> --- a/init/Kconfig
> >> +++ b/init/Kconfig
> >> @@ -534,6 +534,11 @@ config CGROUP_CPUACCT
> >>         Provides a simple Resource Controller for monitoring the
> >>         total CPU consumed by the tasks in a cgroup.
> >>
> >> +config CPUACCT_CPUFREQ_TABLE_MAX
> >> +     int "Max CPUFREQ table size"
> >> +     depends on CGROUP_CPUACCT && CPU_FREQ_TABLE
> >> +     default 32
> >> +
> >
> > I'd say make it just a regular define unless you can think of a reason
> > why a non-developer would want to touch this value.
> 
> I originally thought about doing this, but my concern here is for
> future (or existing) cpu's that have more than 32 speed stepping. This
> will have to be updated as new cpu's are supported in mainline (if
> they exceed the max). Which might be acceptable or not.
> 
> Ideally it would be nice to be able to pull the table size from the
> board-file, or determine the size at run-time instead of compile time.

You should try to discover any current cpu's that have more than 32, if
they exist. (32 seems like a lot)

Then it should be ok to just allow others to patch up the value as
needed, when new cpu's get added with more. There's nothing wrong with
that practice AFAIK ..

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/