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 13:39:40 -0700 [thread overview]
Message-ID: <4AEB4F0C.5020309@sgi.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0910301248390.1090@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
>>
>> 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.
>>
>> (QUESTION: print_summary_bootmsg() is in the __init section and is called
>> from a __cpuinit function, but only when system is booting. Is there a
>> special flag to handle this case?)
>>
>
> That's fine, init.text will still be valid as long as cpuinit.text is and
> there will be no hotplug considerations.
Ok, thanks.
>
>> For Processor Information printout:
>>
>> [ 90.968381] Summary Processor Information for CPUS: 0-639
>> [ 90.972033] Genuine Intel(R) CPU 0000 @ 2.13GHz stepping 04
>> [ 90.981402] CPU: L1 I cache: 32K, L1 D cache: 32K
>> [ 90.985888] CPU: L2 cache: 256K
>> [ 90.988032] CPU: L3 cache: 24576K
>> [ 90.992032] MIN 4266.68 BogoMIPS (lpj=8533371)
>> [ 91.000033] MAX 4267.89 BogoMIPS (lpj=8535789)
>>
>> These lines have been moved to loglevel KERN_DEBUG:
>>
>> CPU: Physical Processor ID:
>> CPU: Processor Core ID:
>> CPU %d/0x%x -> Node %d
>> <cache line sizes per cpu>
>> CPUx is down
>>
>> This message has been changed to loglevel KERN_DEBUG if system is booting
>> and KERN_INFO otherwise:
>>
>> CPU %d is now offline
>>
>> Signed-off-by: Mike Travis <travis@sgi.com>
>> ---
>> arch/x86/include/asm/processor.h | 4
>> arch/x86/kernel/cpu/addon_cpuid_features.c | 4 arch/x86/kernel/cpu/amd.c
>> | 2 arch/x86/kernel/cpu/common.c | 23 +++-
>> arch/x86/kernel/cpu/intel.c | 2
>> arch/x86/kernel/cpu/intel_cacheinfo.c | 22 +---
>> arch/x86/kernel/smpboot.c | 154
>> ++++++++++++++++++++++++++++-
>> kernel/cpu.c | 2 8 files changed, 187
>> insertions(+), 26 deletions(-)
>>
>> --- linux.orig/arch/x86/include/asm/processor.h
>> +++ linux/arch/x86/include/asm/processor.h
>> @@ -111,6 +111,9 @@
>> u16 cpu_core_id;
>> /* Index into per_cpu list: */
>> u16 cpu_index;
>> + /* Interior Cache Sizes: */
>> + u16 l1i, l1d, l2;
>> + u32 l3;
>> #endif
>> unsigned int x86_hyper_vendor;
>> } __attribute__((__aligned__(SMP_CACHE_BYTES)));
>> @@ -169,6 +172,7 @@
>> extern void identify_boot_cpu(void);
>> extern void identify_secondary_cpu(struct cpuinfo_x86 *);
>> extern void print_cpu_info(struct cpuinfo_x86 *);
>> +extern void print_cache_info(struct cpuinfo_x86 *, char *msglvl);
>> extern void init_scattered_cpuid_features(struct cpuinfo_x86 *c);
>> extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
>> extern unsigned short num_cache_leaves;
>> --- linux.orig/arch/x86/kernel/cpu/addon_cpuid_features.c
>> +++ linux/arch/x86/kernel/cpu/addon_cpuid_features.c
>> @@ -128,10 +128,10 @@
>> c->x86_max_cores = (core_level_siblings / smp_num_siblings);
>>
>>
>> - printk(KERN_INFO "CPU: Physical Processor ID: %d\n",
>> + printk(KERN_DEBUG "CPU: Physical Processor ID: %d\n",
>> c->phys_proc_id);
>> if (c->x86_max_cores > 1)
>> - printk(KERN_INFO "CPU: Processor Core ID: %d\n",
>> + printk(KERN_DEBUG "CPU: Processor Core ID: %d\n",
>> c->cpu_core_id);
>> return;
>> #endif
>
> Perhaps an opporunity to move these to pr_debug() instead?
>
Hmm, good idea.
>> --- linux.orig/arch/x86/kernel/cpu/amd.c
>> +++ linux/arch/x86/kernel/cpu/amd.c
>> @@ -376,7 +376,7 @@
>> }
>> numa_set_node(cpu, node);
>>
>> - printk(KERN_INFO "CPU %d/0x%x -> Node %d\n", cpu, apicid, node);
>> + printk(KERN_DEBUG "CPU %d/0x%x -> Node %d\n", cpu, apicid, node);
>> #endif
>> }
>>
>> --- linux.orig/arch/x86/kernel/cpu/common.c
>> +++ linux/arch/x86/kernel/cpu/common.c
>> @@ -475,9 +475,9 @@
>>
>> out:
>> if ((c->x86_max_cores * smp_num_siblings) > 1) {
>> - printk(KERN_INFO "CPU: Physical Processor ID: %d\n",
>> + printk(KERN_DEBUG "CPU: Physical Processor ID: %d\n",
>> c->phys_proc_id);
>> - printk(KERN_INFO "CPU: Processor Core ID: %d\n",
>> + printk(KERN_DEBUG "CPU: Processor Core ID: %d\n",
>> c->cpu_core_id);
>> }
>> #endif
>> @@ -967,6 +967,23 @@
>> #endif
>> }
>>
>> +void __cpuinit print_cache_info(struct cpuinfo_x86 *c, char *lvl)
>> +{
>> + if (c->l1i)
>> + printk("%sCPU: L1 I cache: %dK", lvl, c->l1i);
>> +
>> + if (c->l1d)
>> + printk(KERN_CONT ", L1 D cache: %dK\n", c->l1d);
>> + else
>> + printk(KERN_CONT "\n");
>> +
>> + if (c->l2)
>> + printk("%sCPU: L2 cache: %dK\n", lvl, c->l2);
>> +
>> + if (c->l3)
>> + printk("%sCPU: L3 cache: %dK\n", lvl, c->l3);
>> +}
>> +
>> static __init int setup_disablecpuid(char *arg)
>> {
>> int bit;
>> @@ -1115,7 +1132,7 @@
>> if (cpumask_test_and_set_cpu(cpu, cpu_initialized_mask))
>> panic("CPU#%d already initialized!\n", cpu);
>>
>> - printk(KERN_INFO "Initializing CPU#%d\n", cpu);
>> + printk(KERN_DEBUG "Initializing CPU#%d\n", cpu);
>>
>> clear_in_cr4(X86_CR4_VME|X86_CR4_PVI|X86_CR4_TSD|X86_CR4_DE);
>>
>> --- linux.orig/arch/x86/kernel/cpu/intel.c
>> +++ linux/arch/x86/kernel/cpu/intel.c
>> @@ -267,7 +267,7 @@
>> node = first_node(node_online_map);
>> numa_set_node(cpu, node);
>>
>> - printk(KERN_INFO "CPU %d/0x%x -> Node %d\n", cpu, apicid, node);
>> + printk(KERN_DEBUG "CPU %d/0x%x -> Node %d\n", cpu, apicid, node);
>> #endif
>> }
>>
>> --- linux.orig/arch/x86/kernel/cpu/intel_cacheinfo.c
>> +++ linux/arch/x86/kernel/cpu/intel_cacheinfo.c
>> @@ -489,23 +489,17 @@
>> }
>>
>> if (trace)
>> - printk(KERN_INFO "CPU: Trace cache: %dK uops", trace);
>> - else if (l1i)
>> - printk(KERN_INFO "CPU: L1 I cache: %dK", l1i);
>> -
>> - if (l1d)
>> - printk(KERN_CONT ", L1 D cache: %dK\n", l1d);
>> - else
>> - printk(KERN_CONT "\n");
>> -
>> - if (l2)
>> - printk(KERN_INFO "CPU: L2 cache: %dK\n", l2);
>> -
>> - if (l3)
>> - printk(KERN_INFO "CPU: L3 cache: %dK\n", l3);
>> + printk(KERN_DEBUG "CPU: Trace cache: %dK uops", trace);
>>
>> + c->l1i = l1i;
>> + c->l1d = l1d;
>> + c->l2 = l2;
>> + c->l3 = l3;
>> c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
>>
>> + print_cache_info(c,
>> + system_state == SYSTEM_BOOTING? KERN_DEBUG : KERN_INFO);
>> +
>> return l2;
>> }
>>
>> --- linux.orig/arch/x86/kernel/smpboot.c
>> +++ linux/arch/x86/kernel/smpboot.c
>> @@ -442,6 +442,94 @@
>> return c->llc_shared_map;
>> }
>>
>> +/* Summarize Processor Information */
>> +static void __init summarize_cpu_info(void)
>> +{
>> + cpumask_var_t cpulist, cpusdone;
>> + int cpu;
>> + int err = 0;
>> +
>> + if (!alloc_cpumask_var(&cpulist, GFP_KERNEL))
>> + err = 1;
>> +
>> + else if (!alloc_cpumask_var(&cpusdone, GFP_KERNEL)) {
>> + free_cpumask_var(cpulist);
>> + err = 1;
>> + }
>> +
>> + if (err) {
>> + printk(KERN_INFO "Can't print processor summaries\n");
>> + return;
>> + }
>> +
>> + cpumask_clear(cpusdone);
>> + for (cpu = 0; cpu < nr_cpu_ids; cpu++) {
>> + struct cpuinfo_x86 *c;
>> + int l1i, l1d, l2, l3;
>> + int x86, x86_vendor, x86_model, x86_mask;
>> + char buf[64];
>> + int ncpu;
>> + unsigned long minlpj, maxlpj;
>> +
>> + /* skip if cpu has already been displayed */
>> + if (cpumask_test_cpu(cpu, cpusdone))
>> + continue;
>> +
>> + c = &cpu_data(cpu);
>> + l1i = c->l1i;
>> + l1d = c->l1d;
>> + l2 = c->l2;
>> + l3 = c->l3;
>> + x86 = c->x86;
>> + x86_vendor = c->x86_vendor;
>> + x86_model = c->x86_model;
>> + x86_mask = c->x86_mask;
>> + minlpj = ULONG_MAX;
>> + maxlpj = 0;
>> +
>> + cpumask_clear(cpulist);
>> +
>> + /* collate all cpus with same specifics */
>> + for (ncpu = cpu; ncpu < nr_cpu_ids; ncpu++) {
>> + if (l1i != cpu_data(ncpu).l1i ||
>> + l1d != cpu_data(ncpu).l1d ||
>> + l2 != cpu_data(ncpu).l2 ||
>> + l3 != cpu_data(ncpu).l3 ||
>> + x86 != cpu_data(ncpu).x86 ||
>> + x86_vendor != cpu_data(ncpu).x86_vendor ||
>> + x86_model != cpu_data(ncpu).x86_model ||
>> + x86_mask != cpu_data(ncpu).x86_mask)
>> + continue;
>> +
>> + cpumask_set_cpu(ncpu, cpulist);
>> + cpumask_set_cpu(ncpu, cpusdone);
>> +
>> + if (cpu_data(ncpu).loops_per_jiffy < minlpj)
>> + minlpj = cpu_data(ncpu).loops_per_jiffy;
>> +
>> + if (cpu_data(ncpu).loops_per_jiffy > maxlpj)
>> + maxlpj = cpu_data(ncpu).loops_per_jiffy;
>> + }
>> +
>> + cpulist_scnprintf(buf, sizeof(buf), cpulist);
>> + printk(KERN_INFO
>> + "Summary Processor Information for CPUS: %s\n", buf);
>> +
>> + printk(KERN_INFO);
>> + print_cpu_info(c);
>> + print_cache_info(c, KERN_INFO);
>> +
>> + printk(KERN_INFO "MIN %lu.%02lu BogoMIPS (lpj=%lu)\n",
>> + minlpj/(500000/HZ), (minlpj/(5000/HZ)) % 100, minlpj);
>> +
>> + printk(KERN_INFO "MAX %lu.%02lu BogoMIPS (lpj=%lu)\n",
>> + maxlpj/(500000/HZ), (maxlpj/(5000/HZ)) % 100, maxlpj);
>> + }
>> +
>> + free_cpumask_var(cpusdone);
>> + free_cpumask_var(cpulist);
>> +}
>> +
>> static void impress_friends(void)
>> {
>> int cpu;
>> @@ -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.
Thanks,
Mike
next prev parent reply other threads:[~2009-10-30 20:39 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 [this message]
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
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=4AEB4F0C.5020309@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.