[PATCH v2] kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel

Baoquan He bhe at redhat.com
Mon Mar 17 02:53:06 UTC 2014


Hi HATAYAMA,

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
very well.

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
multi-cpus simultaneously.

Thank you guys hard working on this issue.

Thanks
Baoquan


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 ==
> >>>
> >>>>
> >>>Hi Jerry,
> >>>
> >>>How does it go with virtual machine? I didn't find the "initial apicid"
> >>>on my kvm guest.
> >>>
> >>>Baoquan
> >>>Thanks
> >>>
> 
> Though you've already notice, this is the following issue.
> The patch has already been applied to latest RHEL7 kernel.
> 
> $ git log -1 a477c8594bee3bff639739c48258a8c737ab721e
> commit a477c8594bee3bff639739c48258a8c737ab721e
> Author: HATAYAMA Daisuke <d.hatayama at 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
>     advance.
> 
>     For example, on qemu/KVM, SMP information is specified via -smp
>     command-line option, more specifically, its syntax is:
> 
>       -smp n[,cores=cores][,threads=threads][,sockets=sockets][,maxcpus=maxcpus]
> 
>     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
>     thread.
> 
>     Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
>     Cc: Vivek Goyal <vgoyal at redhat.com>
>     Cc: H. Peter Anvin <hpa at linux.intel.com>
>     Cc: Linus Torvalds <torvalds at linux-foundation.org>
>     Cc: Andrew Morton <akpm at linux-foundation.org>
>     Cc: Peter Zijlstra <a.p.zijlstra at chello.nl>
>     Link: http://lkml.kernel.org/r/5277D644.4090707@jp.fujitsu.com
>     Signed-off-by: Ingo Molnar <mingo at kernel.org>
> 
> 
> >>
> >>Hi Baoquan,
> >>
> >>Without "initial apicid" the awk script will not match and a
> >>"disable_cpu_apicid=N" arguement won't be passed to the crash
> >>kernel.
> >>
> >>This is actually good as the assumption that "CPU 0 == bsp" wouldn't
> >>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.
> 
> -- 
> Thanks.
> HATAYAMA, Daisuke
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/kexec


More information about the kexec mailing list