mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Mike Travis <travis@sgi.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jack Steiner <steiner@sgi.com>, Zhang Rui <rui.zhang@intel.com>,
	Len Brown <lenb@kernel.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Myron Stowe <myron.stowe@hp.com>, Feng Tang <feng.tang@intel.com>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	Yinghai Lu <yhlu.kernel@gmail.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/8] SGI x86_64 UV: Limit the number of ACPI messages
Date: Mon, 26 Oct 2009 23:47:43 +0100	[thread overview]
Message-ID: <200910262347.46292.trenn@suse.de> (raw)
In-Reply-To: <1256354987.17875.6.camel@dc7800.home>

On Saturday 24 October 2009 05:29:47 am Bjorn Helgaas wrote:
> On Fri, 2009-10-23 at 18:37 -0500, Mike Travis wrote:
> > plain text document attachment (limit_acpi)
> > Limit number of ACPI messages of the form:
> >
> > [    0.000000] ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00]
> > lsapic_eid[0x00] enabled)
> >
> > [   99.638655] processor ACPI0007:00: registered as cooling_device0
> >
> > Cc: Zhang Rui <rui.zhang@intel.com>
> > Cc: Len Brown <lenb@kernel.org>
> > Cc: Thomas Renninger <trenn@suse.de>
> > Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > Cc: Alexey Dobriyan <adobriyan@gmail.com>
> > Cc: Myron Stowe <myron.stowe@hp.com>
> > Cc: Feng Tang <feng.tang@intel.com>
> > Cc: Suresh Siddha <suresh.b.siddha@intel.com>
> > Cc: Yinghai Lu <yhlu.kernel@gmail.com>
> > Cc: linux-acpi@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Mike Travis <travis@sgi.com>
> > ---
> >  drivers/acpi/fan.c            |    7 ++++++-
> >  drivers/acpi/processor_core.c |    8 ++++++--
> >  drivers/acpi/tables.c         |   15 ++++++++++-----
> >  3 files changed, 22 insertions(+), 8 deletions(-)
> >
> > --- linux.orig/drivers/acpi/fan.c
> > +++ linux/drivers/acpi/fan.c
> > @@ -243,6 +243,7 @@
> >  	int result = 0;
> >  	int state = 0;
> >  	struct thermal_cooling_device *cdev;
> > +	static int msgcnt;
> >
> >  	if (!device)
> >  		return -EINVAL;
> > @@ -267,7 +268,11 @@
> >  		goto end;
> >  	}
> >
> > -	dev_info(&device->dev, "registered as cooling_device%d\n", cdev->id);
> > +	if (msgcnt < 4 || !limit_console_output(false)) {
> > +		dev_info(&device->dev,
> > +			"registered as cooling_device%d\n", cdev->id);
> > +		msgcnt++;
> > +	}
>
> I'm personally not in favor of printing some, but not all, of these
> messages.  That leads to questions when analyzing a dmesg log, such as
> "Hmm, I see I have 64 CPUs, but only 0-3 are registered as cooling
> devices.  Does that mean something is wrong?"
>
> But I would be glad to see this particular message removed completely.
>
> >  	device->driver_data = cdev;
> >  	result = sysfs_create_link(&device->dev.kobj,
> > --- linux.orig/drivers/acpi/processor_core.c
> > +++ linux/drivers/acpi/processor_core.c
> > @@ -775,6 +775,7 @@
> >  	struct acpi_processor *pr = NULL;
> >  	int result = 0;
> >  	struct sys_device *sysdev;
> > +	static int msgcnt;
> >
> >  	pr = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
> >  	if (!pr)
> > @@ -845,8 +846,11 @@
> >  		goto err_power_exit;
> >  	}
> >
> > -	dev_info(&device->dev, "registered as cooling_device%d\n",
> > -		 pr->cdev->id);
> > +	if (msgcnt < 4 || !limit_console_output(false)) {
> > +		dev_info(&device->dev, "registered as cooling_device%d\n",
> > +			 pr->cdev->id);
> > +		msgcnt++;
> > +	}
If Zhang Rui does not complain you can change these:
..registered as cooling_device..
into dev_dbg() without any condition.
This isn't critical.

Or why not use the more fine grained
ACPI debug facility and change it into:
ACPI_DEBUG_PRINT((ACPI_DB_INFO "..."));
(compare with Documentation/acpi/debug.txt and other
occurences in the same file)
You have to pass:
acpi_dbg_layer=0x20000000
to see it then.
> >
> >  	result = sysfs_create_link(&device->dev.kobj,
> >  				   &pr->cdev->device.kobj,
> > --- linux.orig/drivers/acpi/tables.c
> > +++ linux/drivers/acpi/tables.c
> > @@ -170,11 +170,16 @@
> >  	case ACPI_MADT_TYPE_LOCAL_SAPIC:
> >  		{
> >  			struct acpi_madt_local_sapic *p =
> > -			    (struct acpi_madt_local_sapic *)header;
> > -			printk(KERN_INFO PREFIX
> > -			       "LSAPIC (acpi_id[0x%02x] lsapic_id[0x%02x] lsapic_eid[0x%02x]
> > %s)\n", -			       p->processor_id, p->id, p->eid,
> > -			       (p->lapic_flags & ACPI_MADT_ENABLED) ? "enabled" :
> > "disabled"); +				(struct acpi_madt_local_sapic *)header;
> > +
> > +			if (p->eid < 8 || !limit_console_output(false))
I can't find limit_console_output(), I expect it got introduced by another one 
of your patch series, not send to the acpi list?
Still shouldn't this be:
limit_console_output(true)
instead of:
!limit_console_output(false)

       Thomas

> > +				printk(KERN_INFO PREFIX
> > +					"LSAPIC (acpi_id[0x%02x] "
> > +						"lsapic_id[0x%02x] "
> > +						"lsapic_eid[0x%02x] %s)\n",
> > +					p->processor_id, p->id, p->eid,
> > +					(p->lapic_flags & ACPI_MADT_ENABLED) ?
> > +						"enabled" : "disabled");
>
> I know we print way too much stuff for every processor, but again, I'd
> rather see all CPUs or none.  I think there's a little more value in
> this one than the cooling device one (probably because I do a lot of
> platform bringup), but it could certainly be made KERN_DEBUG and/or
> combined with another processor discovery line.


  parent reply	other threads:[~2009-10-26 20:46 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20091023233743.439628000@alcatraz.americas.sgi.com>
2009-10-23 23:37 ` [PATCH 1/8] SGI x86_64 UV: Add limit console output function Mike Travis
2009-10-24  1:09   ` Frederic Weisbecker
2009-10-26 17:55     ` Mike Travis
2009-11-02 14:15       ` Frederic Weisbecker
2009-10-26  7:02   ` Andi Kleen
2009-10-26 16:10     ` Steven Rostedt
2009-10-26 18:05       ` Mike Travis
2009-10-26 18:51         ` Steven Rostedt
2009-10-26 18:03     ` Mike Travis
2009-10-26 21:55       ` Andi Kleen
2009-10-26 22:07         ` Mike Travis
2009-10-30 19:25         ` [PATCH] x86_64: Limit the number of processor bootup messages Mike Travis
2009-10-30 19:54           ` David Rientjes
2009-10-30 20:39             ` Mike Travis
2009-10-30 23:30               ` David Rientjes
2009-10-31  0:27                 ` Mike Travis
2009-11-02 11:11           ` Andi Kleen
2009-11-02 19:21             ` Mike Travis
2009-11-02 19:34               ` Ingo Molnar
2009-11-02 20:32                 ` Mike Travis
2009-11-04  0:22                   ` Mike Travis
2009-11-04 10:24                     ` Ingo Molnar
2009-11-04 10:31                   ` Ingo Molnar
2009-11-12 22:22               ` Dave Jones
2009-11-12 22:57                 ` H. Peter Anvin
2009-11-12 23:15                   ` Dave Jones
2009-11-13  8:03                     ` Ingo Molnar
2009-11-13  8:11                       ` H. Peter Anvin
2009-11-13  8:18                     ` [tip:x86/debug] x86: Remove the CPU cache size printk's tip-bot for Dave Jones
2009-11-13 22:38                     ` [PATCH] x86: Remove CPU cache size output for non-Intel too Roland Dreier
2009-11-13 22:52                       ` Dave Jones
2009-11-14  0:54                       ` [tip:x86/debug] " tip-bot for Roland Dreier
2009-11-13 16:10                   ` [PATCH] x86_64: Limit the number of processor bootup messages Mike Travis
2009-11-14  0:53                     ` Ingo Molnar
2009-10-23 23:37 ` [PATCH 2/8] SGI x86_64 UV: " Mike Travis
2009-10-26  7:26   ` Andi Kleen
2009-10-23 23:37 ` [PATCH 3/8] SGI x86_64 UV: Limit the number of number of SRAT messages Mike Travis
2009-10-26  7:04   ` Andi Kleen
2009-10-26 18:08     ` Mike Travis
2009-10-27 15:24     ` Mike Travis
2009-10-27 19:45       ` David Rientjes
2009-10-27 20:00         ` Mike Travis
2009-10-27 20:25           ` [patch] x86: reduce srat verbosity in the kernel log David Rientjes
2009-10-27 20:42             ` Mike Travis
2009-10-27 20:48               ` David Rientjes
2009-10-27 23:02                 ` Mike Travis
2009-10-28  3:29                   ` Andi Kleen
2009-10-28  4:08                     ` David Rientjes
2009-10-28  3:53                 ` Yinghai Lu
2009-10-28  4:08                   ` David Rientjes
2009-10-27 20:55             ` Cyrill Gorcunov
2009-10-27 21:06               ` David Rientjes
2009-10-27 21:10                 ` Cyrill Gorcunov
2009-10-28  3:32             ` Andi Kleen
2009-10-28  4:08               ` David Rientjes
2009-10-28  4:11                 ` Andi Kleen
2009-10-28  4:53                   ` [patch v2] " David Rientjes
2009-10-28  5:19                     ` Andi Kleen
2009-10-28  5:24                       ` David Rientjes
2009-11-10 21:08                     ` David Rientjes
2009-11-10 21:33                       ` Ingo Molnar
2009-11-10 21:42                         ` Yinghai Lu
2009-11-10 21:57                           ` Ingo Molnar
2009-11-10 23:09                         ` Mike Travis
2009-11-12 20:56                         ` David Rientjes
2009-11-12 21:14                           ` Mike Travis
2009-11-12 21:20                             ` David Rientjes
2009-10-28 17:02                   ` [patch] " Mike Travis
2009-10-28 20:52                     ` David Rientjes
2009-10-28 21:03                       ` Mike Travis
2009-10-28 21:06                         ` David Rientjes
2009-10-28 21:35                       ` Mike Travis
2009-10-28 21:46                         ` David Rientjes
2009-10-28 22:36                           ` Mike Travis
2009-10-29  8:21                             ` David Rientjes
2009-10-29 16:34                               ` Mike Travis
2009-10-29 19:06                                 ` David Rientjes
2009-10-27 20:16         ` [PATCH 3/8] SGI x86_64 UV: Limit the number of number of SRAT messages Cyrill Gorcunov
2009-10-27 20:23           ` Mike Travis
2009-10-27 20:33             ` Cyrill Gorcunov
2009-10-23 23:37 ` [PATCH 4/8] SGI x86_64 UV: Limit the number of ACPI messages Mike Travis
2009-10-24  3:29   ` Bjorn Helgaas
2009-10-26 18:15     ` Mike Travis
2009-10-26 22:47     ` Thomas Renninger [this message]
2009-10-26 21:25       ` Mike Travis
2009-10-27 15:27     ` Mike Travis
2009-10-27 15:51       ` Bjorn Helgaas
2009-10-23 23:37 ` [PATCH 5/8] SGI x86_64 UV: Limit the number of firmware messages Mike Travis
2009-10-23 23:37 ` [PATCH 6/8] SGI x86_64 UV: Limit the number of microcode messages Mike Travis
2009-10-24 20:09   ` Dmitry Adamushko
2009-10-24 21:09     ` Tigran Aivazian
2009-10-24 22:45       ` Dmitry Adamushko
2009-10-25 16:37         ` Ingo Molnar
2009-10-25 17:11           ` Arjan van de Ven
2009-10-25 17:27             ` Ingo Molnar
2009-10-26 18:33               ` Mike Travis
2009-10-26 18:29             ` Mike Travis
2009-10-26 18:29           ` Mike Travis
2009-10-26 20:11             ` Dmitry Adamushko
2009-10-27 15:21               ` Mike Travis
2009-10-26 18:25         ` Mike Travis
2009-10-26 19:27           ` Borislav Petkov
2009-10-30 19:40         ` [PATCH] x86_64: " Mike Travis
2009-10-26 18:24       ` [PATCH 6/8] SGI x86_64 UV: " Mike Travis
2009-10-26 18:18     ` Mike Travis
2009-10-26  7:05   ` Andi Kleen
2009-10-26 18:34     ` Mike Travis
2009-10-23 23:37 ` [PATCH 7/8] SGI x86_64 UV: Limit the number of scheduler debug messages Mike Travis
2009-10-23 23:37 ` [PATCH 8/8] SGI x86_64 UV: Limit the number of cpu is down messages Mike Travis

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=200910262347.46292.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=feng.tang@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=myron.stowe@hp.com \
    --cc=rui.zhang@intel.com \
    --cc=steiner@sgi.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=travis@sgi.com \
    --cc=yhlu.kernel@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome