All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: David Rientjes <rientjes@google.com>
Cc: Ingo Molnar <mingo@elte.hu>, Andi Kleen <ak@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Roland Dreier <rdreier@cisco.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Tejun Heo <tj@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
	Jack Steiner <steiner@sgi.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	x86@kernel.org, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86_64: Limit the number of processor bootup messages
Date: Fri, 30 Oct 2009 17:27:40 -0700	[thread overview]
Message-ID: <4AEB847C.4020003@sgi.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0910301620260.31387@chino.kir.corp.google.com>



David Rientjes wrote:
> On Fri, 30 Oct 2009, Mike Travis wrote:
> 
>>>> x86_64: Limit the number of processor bootup messages
>>>>
> 
> Is this really only limited to 64 bit?

[That was a quick edit to change it from SGI X86_64 UV and it didn't
occur to me to remove the _64. :-)]

> 
>>>> With a large number of processors in a system there is an excessive amount
>>>> of messages sent to the system console.  It's estimated that with 4096
>>>> processors in a system, and the console baudrate set to 56K, the startup
>>>> messages will take about 84 minutes to clear the serial port.
>>>>
>>>> This set of patches limits the number of repetitious messages which
>>>> contain
>>>> no additional information.  Much of this information is obtainable from
>>>> the
>>>> /proc and /sysfs.   Most of the messages are also sent to the kernel log
>>>> buffer as KERN_DEBUG messages so it can be used to examine more closely
>>>> any
>>>> details specific to a processor.
>>>>
>>>> The list of message transformations....
>>>>
>>>> For system_state == SYSTEM_BOOTING:
>>>>
>>>> 	[   25.388280] Booting Processors 1-7,320-327, Node 0
>>>> 	[   26.064742] Booting Processors 8-15,328-335, Node 1
>>>> 	[   26.837006] Booting Processors 16-31,336-351, Nodes 2-3
>>>> 	[   28.440427] Booting Processors 32-63,352-383, Nodes 4-7
>>>> 	[   31.640450] Booting Processors 64-127,384-447, Nodes 8-15
>>>> 	[   38.041430] Booting Processors 128-255,448-575, Nodes 16-31
>>>> 	[   50.917504] Booting Processors 256-319,576-639, Nodes 32-39
>>>> 	[   90.964169] Brought up 640 CPUs
>>>>
>>>> The range of processors increases as a power of 2, so 4096 CPU's should
>>>> only take 12 lines.
>>>>
> 
> On your particular machine, yes, but there's no x86 restriction on the 
> number of cpus per node.

Yes, my comment is wrong.  The limit would be 10 lines for the current kernel
limit of 512 nodes.

> 
>>>> @@ -671,6 +759,50 @@
>>>> 	complete(&c_idle->done);
>>>> }
>>>>
>>>> +/* Summarize the "Booting processor ..." startup messages */
>>>> +static void __init print_summary_bootmsg(int cpu)
>>>> +{
>>>> +	static int next_node, node_shift;
>>>> +	int node = cpu_to_node(cpu);
>>>> +
>>>> +	if (node >= next_node) {
>>>> +		cpumask_var_t cpulist;
>>>> +
>>>> +		node = next_node;
>>>> +		next_node = 1 << node_shift;
>>>> +		node_shift++;
>>>> +
>>>> +		if (alloc_cpumask_var(&cpulist, GFP_KERNEL)) {
>>>> +			int i, tmp, last_node = node;
>>>> +			char buf[32];
>>>> +
>>>> +			cpumask_clear(cpulist);
>>>> +			for_each_present_cpu(i) {
>>>> +				if (i == 0)	/* boot cpu */
>>>> +					continue;
>>>> +
>>>> +				tmp = cpu_to_node(i);
>>>> +				if (node <= tmp && tmp < next_node) {
>>>> +					cpumask_set_cpu(i, cpulist);
>>>> +					if (last_node < tmp)
>>>> +						last_node = tmp;
>>>> +				}
>>>> +			}
>>>> +			if (cpumask_weight(cpulist)) {
>>>> +				cpulist_scnprintf(buf, sizeof(buf), cpulist);
>>>> +				printk(KERN_INFO "Booting Processors %s,",
>>>> buf);
>>>> +
>>>> +				if (node == last_node)
>>>> +					printk(KERN_CONT " Node %d\n", node);
>>>> +				else
>>>> +					printk(KERN_CONT " Nodes %d-%d\n",
>>>> +						node, last_node);
>>>> +			}
>>>> +			free_cpumask_var(cpulist);
>>>> +		}
>>>> +	}
>>>> +}
>>>> +
>>>> /*
>>>>  * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad
>>>>  * (ie clustered apic addressing mode), this is a LOGICAL apic ID.
>>> Why isn't cpumask_of_node() available yet?
>> I'll try that.  It gets a bit tricky in specifying the actual last node that
>> is being booted.
>>
> 
> Why do you need to call print_summary_bootmsg() for each cpu?  It seems 
> like you'd be able to move this out to a single call to a new function:
> 
> void __init print_summary_bootmsg(void)
> {
> 	char buf[128];
> 	int nid;
> 
> 	for_each_online_node(nid) {
> 		const struct cpumask *mask = cpumask_of_node(nid);
> 
> 		if (cpumask_empty(mask))
> 			continue;
> 		cpulist_scnprintf(buf, sizeof(buf), cpumask_of_node(nid));
> 		pr_info("Booting Processors %s, Node %d\n", buf, nid);
> 	}
> }

Well one thing I did find out, cpumask_of_node (or more specifically
node_to_cpumask_map[] is filled in while the CPU's are booting, not
before.

Also, the above could potentially print 512 lines of boot messages before
booting cpu 1. The printk times also would not be accurate for each group
of cpus.  And there's something to be said about actually doing what it
is you say you are doing. ;-)

	Booting Processors 0-15  Node 0
	Booting Processors 16-31  Node 1
	<Here you expect cpus 0-15 to have already been booted.>

Why not just say:

        cpulist_scnprintf(buf, sizeof(buf), cpu_present_mask);
        pr_info("Booting Processors %s\n", buf);

Since the node -> cpu map can be printed much more efficiently some other way?

For example:

	Nodes 0-7:  0-7,512-519   8-15,520-527   ...

would shrink it to 64 lines max.

(Note, it's important to include the "cpu_present_mask" because cpus can
be powered on disabled, and be booted later on, to decrease the initial
system startup time.)

A request was made (by AK?) that getting a general sense of progress is
a "good thing".  I wanted to avoid something more mundane like dots or
sequential numbers.  The one thing that Andi mentioned that I haven't
figured out is how to "delay print" specific cpu info in the case of a
boot error.  I suppose one way would be to save the current position in
the kernel log buffer at the start of each cpu boot, and print that to
the console in case of an error?

Thanks,
Mike


  reply	other threads:[~2009-10-31  0:27 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 [this message]
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
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=4AEB847C.4020003@sgi.com \
    --to=travis@sgi.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@suse.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rdreier@cisco.com \
    --cc=rdunlap@xenotime.net \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=seto.hidetoshi@jp.fujitsu.com \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=x86@kernel.org \
    --cc=yinghai@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 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.