From: Andi Kleen <andi@firstfloor.org>
To: Len Brown <lenb@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
linux-pm@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
x86@kernel.org
Subject: Re: [PATCH RESEND] tools: add power/x86/x86_energy_perf_policy to program MSR_IA32_ENERGY_PERF_BIAS
Date: Wed, 17 Nov 2010 12:35:52 +0100 [thread overview]
Message-ID: <8739r0rxlz.fsf@basil.nowhere.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1011151103280.2939@x980> (Len Brown's message of "Mon, 15 Nov 2010 11:07:04 -0500 (EST)")
Len Brown <lenb@kernel.org> writes:
> @@ -0,0 +1,7 @@
> +x86_energy_perf_policy : x86_energy_perf_policy.c
> +
> +clean :
> + rm -f x86_energy_perf_policy
> +
> +install :
> + install x86_energy_perf_policy /usr/bin/x86_energy_perf_policy
It's not clear to me how this Makefile ensures it's only
build on x86.
If someone on another architecture does a full tools build
in the future (I think that is not wired up yet, but should
eventually) such a mechanism would be needed.
> +
> +/*
> + * Usage:
...
This full comment and parts of the following comments describing the
semantics need to be available somewhere to the user who may not have
easy access to the source. Can you make it display in usage or convert
it to a manpage? I would prefer a manpage
> +
> +cmdline(int argc, char **argv) {
No type?
> + int opt;
> +
> + progname = argv[0];
> +
> + while ((opt = getopt(argc, argv, "+rvc:")) != -1) {
Maybe it's me, but I prefer having long options too (getopt_long)
These are easier to memorize.
> +
> + /*
> + * if no -r , then must be one additional optind
> + */
> + if (!read_only) {
> +
> + if (argc != optind + 1) {
> + printf("must supply -r or policy param\n");
> + usage();
> + exit(-1);
-1 is an unusual exit code. Better use 1.
An obvious improvement would be to put the exit() into usage()
> + }
> +
> + if (!strcmp("performance", argv[optind])) {
> + new_bias = BIAS_PERFORMANCE;
> + } else if (!strcmp("normal", argv[optind])) {
> + new_bias = BIAS_BALANCE;
> + } else if (!strcmp("powersave", argv[optind])) {
> + new_bias = BIAS_POWERSAVE;
> + } else {
> + new_bias = atoll(argv[optind]);
If you used strtoull() you could actually check if the input
is really a number (end == argv[optind])
> + eax = ebx = ecx = edx = 0;
> +
> + asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx),
> + "=d" (edx) : "a" (0));
Strictly for 386/early 486 you would need to check if cpuid
is available using pushf too. Perhaps it's safer to use cpuinfo
> +
> +check_dev_msr() {
Return type missing again
> + struct stat sb;
> +
> + if (stat("/dev/cpu/0/msr", &sb)) {
> + printf("no /dev/cpu/0/msr\n");
This will fail if we eventually implement cpu 0 hotplug...
Better readdir or similar.
> + printf("Try \"# modprobe msr\"\n");
> + exit(-5);
Again -5 is unusual.
> + char msr_path[32];
> + int retval;
> + int fd;
> +
> + sprintf(msr_path, "/dev/cpu/%d/msr", cpu);
> + fd = open(msr_path, O_RDONLY);
> + if (fd < 0) {
> + perror(msr_path);
> + exit(-1);
This should be a soft error because the CPU can go away
any time.
> +/*
> + * run func() on every cpu in /dev/cpu
> + */
> +void for_every_cpu(void (func)(int))
> +{
> + FILE *fp;
> + int cpu_count;
> + int retval;
> +
> + fp = fopen(proc_stat, "r");
Using /proc/stat to get the number of CPUs is unusual
and you don't handle holes in the cpu numbers which
can happen due to hotplug.
I would just readdir or fnmatch the MSR /dev/cpu/* directories.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-11-17 11:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-16 21:05 RFC: /sys/power/policy_preference Len Brown
2010-06-17 6:03 ` [linux-pm] " Igor.Stoppa
2010-06-17 19:00 ` Len Brown
2010-06-17 16:14 ` Victor Lowther
2010-06-17 19:02 ` Len Brown
2010-06-17 22:23 ` Victor Lowther
2010-06-18 5:56 ` Len Brown
2010-06-18 11:55 ` Victor Lowther
2010-06-19 15:17 ` Vaidyanathan Srinivasan
2010-06-19 19:04 ` Rafael J. Wysocki
2010-06-17 20:48 ` Mike Chan
2010-06-18 6:25 ` Len Brown
2010-06-21 20:10 ` [linux-pm] " Dipankar Sarma
2010-09-28 16:17 ` x86_energy_perf_policy.c Len Brown
2010-10-23 4:40 ` [PATCH] tools: add x86_energy_perf_policy to program MSR_IA32_ENERGY_PERF_BIAS Len Brown
2010-10-27 3:23 ` Andrew Morton
2010-10-27 6:01 ` Ingo Molnar
2010-10-27 11:43 ` Arnaldo Carvalho de Melo
2010-11-15 16:07 ` [PATCH RESEND] tools: add power/x86/x86_energy_perf_policy " Len Brown
2010-11-17 11:35 ` Andi Kleen [this message]
2010-11-22 20:13 ` Len Brown
2010-11-22 20:33 ` Andi Kleen
2010-11-23 4:48 ` Len Brown
2010-11-24 5:31 ` [PATCH v2] tools: create power/x86/x86_energy_perf_policy Len Brown
2010-11-25 5:52 ` Chen Gong
2010-11-25 8:59 ` Chen Gong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8739r0rxlz.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=gregkh@suse.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox