From: Roland Dreier <rdreier@cisco.com>
To: ykzhao <yakui.zhao@intel.com>
Cc: Len Brown <lenb@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] ACPI: Kill overly verbose "power state" log messages
Date: Fri, 25 Sep 2009 09:01:43 -0700 [thread overview]
Message-ID: <adak4znypw8.fsf@cisco.com> (raw)
In-Reply-To: <1253839597.3609.459.camel@localhost.localdomain> (ykzhao's message of "Fri, 25 Sep 2009 08:46:37 +0800")
Len, I see I messed up editing my changelog message, see below...
> > I was recently lucky enough to get a 64-CPU system. The processors
> > actually have T-states, so my kernel log ends up with 64 lines like:
> >
> > ACPI: CPU0 (power states: C1[C1] C2[C3])
> >
> > This is pretty useless clutter because this info is already available
> > after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as
> > well as /proc/acpi/processor/CPU*/power.
> >
> > So just delete the code that prints the throttling states in
> > processor_idle.c.
> It seems that it is unnecessary to delete the C-state info.
Sorry, this is a little too terse for me to know what you mean.
Certainly it's not useful to have 64 copies of
ACPI: CPU0 (power states: C1[C1] C2[C3])
in the kernel log on a big box, when all 64 processors are going to
support the same C-states. However, I don't see what the use of having
even one copy in the boot log is, when I can easily get that info at
runtime from /proc/acpi/processor/CPU*/power.
Anyway, Len, I see I copy-and-pasted too quickly from my T-state patch
submission... if you want to apply, a version with better changelog would be:
<--- snip --->
I was recently lucky enough to get a 64-CPU system, so my kernel log
ends up with 64 lines like:
ACPI: CPU0 (power states: C1[C1] C2[C3])
This is pretty useless clutter because this info is already available
after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as
well as /proc/acpi/processor/CPU*/power.
So just delete the code that prints the C-states in processor_idle.c.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
drivers/acpi/processor_idle.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index cc61a62..706eacf 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1214,13 +1214,6 @@ int __cpuinit acpi_processor_power_init(struct acpi_processor *pr,
acpi_processor_setup_cpuidle(pr);
if (cpuidle_register_device(&pr->power.dev))
return -EIO;
-
- printk(KERN_INFO PREFIX "CPU%d (power states:", pr->id);
- for (i = 1; i <= pr->power.count; i++)
- if (pr->power.states[i].valid)
- printk(" C%d[C%d]", i,
- pr->power.states[i].type);
- printk(")\n");
}
#ifdef CONFIG_ACPI_PROCFS
/* 'power' [R] */
WARNING: multiple messages have this Message-ID (diff)
From: Roland Dreier <rdreier@cisco.com>
To: ykzhao <yakui.zhao@intel.com>
Cc: Len Brown <lenb@kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi\@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] ACPI: Kill overly verbose "power state" log messages
Date: Fri, 25 Sep 2009 09:01:43 -0700 [thread overview]
Message-ID: <adak4znypw8.fsf@cisco.com> (raw)
In-Reply-To: <1253839597.3609.459.camel@localhost.localdomain> (ykzhao's message of "Fri, 25 Sep 2009 08:46:37 +0800")
Len, I see I messed up editing my changelog message, see below...
> > I was recently lucky enough to get a 64-CPU system. The processors
> > actually have T-states, so my kernel log ends up with 64 lines like:
> >
> > ACPI: CPU0 (power states: C1[C1] C2[C3])
> >
> > This is pretty useless clutter because this info is already available
> > after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as
> > well as /proc/acpi/processor/CPU*/power.
> >
> > So just delete the code that prints the throttling states in
> > processor_idle.c.
> It seems that it is unnecessary to delete the C-state info.
Sorry, this is a little too terse for me to know what you mean.
Certainly it's not useful to have 64 copies of
ACPI: CPU0 (power states: C1[C1] C2[C3])
in the kernel log on a big box, when all 64 processors are going to
support the same C-states. However, I don't see what the use of having
even one copy in the boot log is, when I can easily get that info at
runtime from /proc/acpi/processor/CPU*/power.
Anyway, Len, I see I copy-and-pasted too quickly from my T-state patch
submission... if you want to apply, a version with better changelog would be:
<--- snip --->
I was recently lucky enough to get a 64-CPU system, so my kernel log
ends up with 64 lines like:
ACPI: CPU0 (power states: C1[C1] C2[C3])
This is pretty useless clutter because this info is already available
after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as
well as /proc/acpi/processor/CPU*/power.
So just delete the code that prints the C-states in processor_idle.c.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
drivers/acpi/processor_idle.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index cc61a62..706eacf 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1214,13 +1214,6 @@ int __cpuinit acpi_processor_power_init(struct acpi_processor *pr,
acpi_processor_setup_cpuidle(pr);
if (cpuidle_register_device(&pr->power.dev))
return -EIO;
-
- printk(KERN_INFO PREFIX "CPU%d (power states:", pr->id);
- for (i = 1; i <= pr->power.count; i++)
- if (pr->power.states[i].valid)
- printk(" C%d[C%d]", i,
- pr->power.states[i].type);
- printk(")\n");
}
#ifdef CONFIG_ACPI_PROCFS
/* 'power' [R] */
next prev parent reply other threads:[~2009-09-25 16:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-24 21:52 [PATCH] ACPI: Kill overly verbose "power state" log messages Roland Dreier
2009-09-25 0:46 ` ykzhao
2009-09-25 16:01 ` Roland Dreier [this message]
2009-09-25 16:01 ` Roland Dreier
2009-09-27 8:01 ` Len Brown
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=adak4znypw8.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yakui.zhao@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.