lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 06 Apr 2010 12:58:10 -0700
From:	Daniel Walker <dwalker@...o99.com>
To:	Mike Chan <mike@...roid.com>
Cc:	menage@...gle.com, balbir@...ibm.com, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] sched: cpuacct: Track cpuusage per cpu frequency

On Tue, 2010-04-06 at 12:43 -0700, Mike Chan wrote:
> On Tue, Apr 6, 2010 at 10:48 AM, Daniel Walker <dwalker@...o99.com> 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@...roid.com>
> >> ---
> >>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ