Thanks for telling. I tested it on my KVM with 4 cpus, kernel is
3.10.0-110.el7.x86_64, the "nr_cpus=1" is erased, dumping is working
I have to say this is awesome. Up to now the long-term disrupting
multi-cpus problem has been solved. I guess next will be the performance
improvement trying, especially the dumping splitting and running on
Thank you guys hard working on this issue.
On 03/14/14 at 07:33pm, HATAYAMA Daisuke wrote:
(2014/02/25 10:58), Baoquan He wrote:
>On 02/24/14 at 12:22pm, Jerry Hoemann wrote:
>>On Mon, Feb 24, 2014 at 10:38:00AM +0800, Baoquan He wrote:
>>>On 02/20/14 at 06:09pm, Jerry Hoemann wrote:
>>>>== Version 2 ==
>>>How does it go with virtual machine? I didn't find the "initial
>>>on my kvm guest.
Though you've already notice, this is the following issue.
The patch has already been applied to latest RHEL7 kernel.
$ git log -1 a477c8594bee3bff639739c48258a8c737ab721e
Author: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com>
Date: Tue Nov 5 02:15:48 2013 +0900
x86/cpu: Always print SMP information in /proc/cpuinfo
Currently show_cpuinfo_core() displays cpu core information only if
the number of threads per a whole cores is 2 or larger.
However, this condition doesn't care about the number of
sockets. For example, this condition doesn't hold on systems
with two logical cpus consisting of two sockets and a single
core on each socket - yet the topology information would be
interesting to see in that case as well.
I don't know whether or not there are processors in real world
by which such configurations are possible, but at least on
vitual machine environments, such configuration can occur,
typically when no explicit SMP information is provided in
For example, on qemu/KVM, SMP information is specified via -smp
command-line option, more specifically, its syntax is:
If this is not specified, qemu tells configuration with
n-sockets, 1-core and 1-thread to the guest machine, on which
guest, MP information is not displayed in /proc/cpuinfo.
I saw this situation on VMWare guest environment, too.
To fix this issue, this patch simply removes the condition
because this information is useful even if there's only 1
Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com>
Cc: Vivek Goyal <vgoyal(a)redhat.com>
Cc: H. Peter Anvin <hpa(a)linux.intel.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra(a)chello.nl>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
>>Without "initial apicid" the awk script will not match and a
>>"disable_cpu_apicid=N" arguement won't be passed to the crash
>>This is actually good as the assumption that "CPU 0 == bsp"
>>hold in a virutal environment.
As the above patch, this is irrelevant to virtual environment.
>>Howerver, this does mean that a kvm instance might still have difficultly
>>specifying nr_cpus > 1 for crash kernel.
It's better to make kdumpctl fail if BSP is unknown and nr_cpus > 1 is
specified in command line.
>>Longer term we should look into having something more explicit exported
>>to user space saying which CPU is ths bsp. I know Vivek has mentioned
>>this previously. If this information was available in both real hardware
>>and virtual system, the above test could be modified.
This is easy. On BSP, BP bit on MSR is set, while on AP not set. Difference
between BSP and AP is that only. So, it's enough to indicate BSP in
/proc/cpuinfo if BP bit is set to the cpu.
kexec mailing list