2:09 a.m.
== Version 2 ==
Addresses Vivek's review comments:
1. Don't force numeric in awk script snipet.
2. Command line processing is moved from load_kernel to new function
"prepare_cmdline." This new function is responsible for
setting up the command line passed to KEXEC.
3. New function "append_cmdline" is added to append {argument,value}
pair to command line if argument is not already present.
== Version 1 ==
A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple
processors in the crash kernel.
To do this safely the crash kernel needs to know which CPU was the 1st
kernel BSP (bootstrap processor) so that the crash kernel will NOT send
the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel
BSP, some systems may reset or hang.
The EFI spec doesn't require that any particular processor is chosen
as the BSP and the CPU (and its apic id) can change from one boot to
the next. Hence automating the selection of CPU to disable if the
system would panic is desired.
This patch updates the kdumpctl script to get the "initial apicid"
of CPU 0 in the first kernel and will pass this as the
"disable_cpu_apicid=" arguement to kexec if it wasn't explicitly
set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
CPU 0 is chosen as it is the processor thats execute the OS
initialization
code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
See associated Red Hat Bugzilla(s) for additional background material:
https://bugzilla.redhat.com/show_bug.cgi?id=1059031
https://bugzilla.redhat.com/show_bug.cgi?id=980621
---
kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/kdumpctl b/kdumpctl
index 46ae633..0a0bab1 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -41,6 +41,59 @@ function remove_cmdline_param()
echo $cmdline
}
+#
+# This function returns the "initial apicid" of the
+# boot cpu (cpu 0) if present.
+#
+function get_bootcpu_initial_apicid()
+{
+ awk ' \
+ BEGIN { CPU = "-1"; } \
+ $1=="processor" && $2==":" { CPU = $NF; } \
+ CPU=="0" && /initial apicid/ { print $NF; } \
+ ' \
+ /proc/cpuinfo
+}
+
+#
+# This function appends argument "$2=$3" to string ($1) if not already
present.
+#
+function append_cmdline()
+{
+ local cmdline=$1
+ local newstr=${cmdline/$2/""}
+
+ # unchanged str implies argument wasn't there
+ if [ "$cmdline" == "$newstr" ]; then
+ cmdline="${cmdline} ${2}=${3}"
+ fi
+
+ echo $cmdline
+}
+
+# This function performs a series of edits on the command line
+function prepare_cmdline()
+{
+ local cmdline;
+ if [ -z "$KDUMP_COMMANDLINE" ]; then
+ cmdline=`cat /proc/cmdline`
+ else
+ cmdline=${KDUMP_COMMANDLINE}
+ fi
+ cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
+
+
+ cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
+
+ local id=`get_bootcpu_initial_apicid`
+ if [ ! -z ${id} ] ; then
+ cmdline=`append_cmdline "${cmdline}" disable_cpu_apicid ${id}`
+ fi
+
+ echo $cmdline
+}
+
+
function save_core()
{
coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`"
@@ -244,13 +297,7 @@ function load_kdump()
fi
fi
- if [ -z "$KDUMP_COMMANDLINE" ]
- then
- KDUMP_COMMANDLINE=`cat /proc/cmdline`
- fi
- KDUMP_COMMANDLINE=`remove_cmdline_param "$KDUMP_COMMANDLINE" crashkernel
hugepages hugepagesz`
-
- KDUMP_COMMANDLINE="${KDUMP_COMMANDLINE} ${KDUMP_COMMANDLINE_APPEND}"
+ KDUMP_COMMANDLINE=`prepare_cmdline`
$KEXEC $KEXEC_ARGS $standard_kexec_args \
--command-line="$KDUMP_COMMANDLINE" \
--
1.8.5.3
2:14 p.m.
New subject: [PATCH v2] kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel
On Thu, Feb 20, 2014 at 06:09:30PM -0700, Jerry Hoemann wrote:
== Version 2 ==
Addresses Vivek's review comments:
1. Don't force numeric in awk script snipet.
2. Command line processing is moved from load_kernel to new function
"prepare_cmdline." This new function is responsible for
setting up the command line passed to KEXEC.
3. New function "append_cmdline" is added to append {argument,value}
pair to command line if argument is not already present.
== Version 1 ==
A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple
processors in the crash kernel.
To do this safely the crash kernel needs to know which CPU was the 1st
kernel BSP (bootstrap processor) so that the crash kernel will NOT send
the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel
BSP, some systems may reset or hang.
The EFI spec doesn't require that any particular processor is chosen
as the BSP and the CPU (and its apic id) can change from one boot to
the next. Hence automating the selection of CPU to disable if the
system would panic is desired.
This patch updates the kdumpctl script to get the "initial apicid"
of CPU 0 in the first kernel and will pass this as the
"disable_cpu_apicid=" arguement to kexec if it wasn't explicitly
set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
CPU 0 is chosen as it is the processor thats execute the OS
initialization
code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
See associated Red Hat Bugzilla(s) for additional background material:
https://bugzilla.redhat.com/show_bug.cgi?id=1059031
https://bugzilla.redhat.com/show_bug.cgi?id=980621
---
kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 54 insertions(+), 7 deletions(-)
Thanks Jerry. This version looks good to me.
Can you please test the disable_cpu_apicid override functionality by
specifying it /etc/sysconfig/kdump and make sure it is working.
Acked-by: Vivek Goyal <vgoyal(a)redhat.com>
Thanks
Vivek
diff --git a/kdumpctl b/kdumpctl
index 46ae633..0a0bab1 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -41,6 +41,59 @@ function remove_cmdline_param()
echo $cmdline
}
+#
+# This function returns the "initial apicid" of the
+# boot cpu (cpu 0) if present.
+#
+function get_bootcpu_initial_apicid()
+{
+ awk ' \
+ BEGIN { CPU = "-1"; } \
+ $1=="processor" && $2==":" { CPU = $NF; } \
+ CPU=="0" && /initial apicid/ { print $NF; } \
+ ' \
+ /proc/cpuinfo
+}
+
+#
+# This function appends argument "$2=$3" to string ($1) if not already
present.
+#
+function append_cmdline()
+{
+ local cmdline=$1
+ local newstr=${cmdline/$2/""}
+
+ # unchanged str implies argument wasn't there
+ if [ "$cmdline" == "$newstr" ]; then
+ cmdline="${cmdline} ${2}=${3}"
+ fi
+
+ echo $cmdline
+}
+
+# This function performs a series of edits on the command line
+function prepare_cmdline()
+{
+ local cmdline;
+ if [ -z "$KDUMP_COMMANDLINE" ]; then
+ cmdline=`cat /proc/cmdline`
+ else
+ cmdline=${KDUMP_COMMANDLINE}
+ fi
+ cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz`
+
+
+ cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}"
+
+ local id=`get_bootcpu_initial_apicid`
+ if [ ! -z ${id} ] ; then
+ cmdline=`append_cmdline "${cmdline}" disable_cpu_apicid ${id}`
+ fi
+
+ echo $cmdline
+}
+
+
function save_core()
{
coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`"
@@ -244,13 +297,7 @@ function load_kdump()
fi
fi
- if [ -z "$KDUMP_COMMANDLINE" ]
- then
- KDUMP_COMMANDLINE=`cat /proc/cmdline`
- fi
- KDUMP_COMMANDLINE=`remove_cmdline_param "$KDUMP_COMMANDLINE" crashkernel
hugepages hugepagesz`
-
- KDUMP_COMMANDLINE="${KDUMP_COMMANDLINE} ${KDUMP_COMMANDLINE_APPEND}"
+ KDUMP_COMMANDLINE=`prepare_cmdline`
$KEXEC $KEXEC_ARGS $standard_kexec_args \
--command-line="$KDUMP_COMMANDLINE" \
--
1.8.5.3
7:52 p.m.
New subject: [PATCH v2] kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel
On Fri, Feb 21, 2014 at 08:14:10AM -0500, Vivek Goyal wrote:
On Thu, Feb 20, 2014 at 06:09:30PM -0700, Jerry Hoemann wrote:
> == Version 2 ==
>
> Addresses Vivek's review comments:
>
> 1. Don't force numeric in awk script snipet.
>
> 2. Command line processing is moved from load_kernel to new function
> "prepare_cmdline." This new function is responsible for
> setting up the command line passed to KEXEC.
>
> 3. New function "append_cmdline" is added to append {argument,value}
> pair to command line if argument is not already present.
>
> == Version 1 ==
>
> A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple
> processors in the crash kernel.
>
> To do this safely the crash kernel needs to know which CPU was the 1st
> kernel BSP (bootstrap processor) so that the crash kernel will NOT send
> the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel
> BSP, some systems may reset or hang.
>
> The EFI spec doesn't require that any particular processor is chosen
> as the BSP and the CPU (and its apic id) can change from one boot to
> the next. Hence automating the selection of CPU to disable if the
> system would panic is desired.
>
> This patch updates the kdumpctl script to get the "initial apicid"
> of CPU 0 in the first kernel and will pass this as the
> "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly
> set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
>
> CPU 0 is chosen as it is the processor thats execute the OS
> initialization
> code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
>
> See associated Red Hat Bugzilla(s) for additional background material:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1059031
> https://bugzilla.redhat.com/show_bug.cgi?id=980621
> ---
> kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 54 insertions(+), 7 deletions(-)
Thanks Jerry. This version looks good to me.
Can you please test the disable_cpu_apicid override functionality by
specifying it /etc/sysconfig/kdump and make sure it is working.
Acked-by: Vivek Goyal <vgoyal(a)redhat.com>
Thanks
Vivek
A. On a prototype system that exihibits the underlying problem w/ INIT
to the 1st kernel BSP causing a hang.
B. System running RHEL 7.0 snap 6 plus kernel w/ Daisuke's patch
C. Using the modified kdumpctl script I sent yesterday.
D. Processor w/ APIC ID == 0 was deconfigured, so BSP has APIC ID == 2.
1) ran five crash dumps injecting error (echo c > /proc/sysrq-trigger)
on random cpu successfully. crash kernel had nr_cpus=4.
Crash dumps were successful.
2) Then configured /etc/sysconf/kdump to specify disable_cpu_apicid=0.
Injected error on CPU 24. This time the crash kernel hung when
bringing other processors on line.
The second test shows the crash kernel was looking to avoid INIT
of APICID 0, not as it should of in the case of this system which
has BSP w/ initial apicid of 2. (note, in development of the
script I had an echo of the command line argument and tested
this case to verify that explicit override was honored.)
I used RHEL 7.0 as I had access to RHEL 7 kernel that had Daisuke's
patch applied (not sure about Fedora kernels in this respect.)
Both RHEL 7.0 and Fedora 20 had the same kdumpctl scripts prior
to my modifications.
Jerry
--
----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett-Packard
3404 E Harmony Rd. MS 57 phone: (970) 898-1022
Ft. Collins, CO 80528 FAX: (970) 898-XXXX
email: jerry.hoemann(a)hp.com
----------------------------------------------------------------------------
10:58 a.m.
(2014/02/22 3:52), Jerry Hoemann wrote:
On Fri, Feb 21, 2014 at 08:14:10AM -0500, Vivek Goyal wrote:
> On Thu, Feb 20, 2014 at 06:09:30PM -0700, Jerry Hoemann wrote:
>> == Version 2 ==
>>
>> Addresses Vivek's review comments:
>>
>> 1. Don't force numeric in awk script snipet.
>>
>> 2. Command line processing is moved from load_kernel to new function
>> "prepare_cmdline." This new function is responsible for
>> setting up the command line passed to KEXEC.
>>
>> 3. New function "append_cmdline" is added to append {argument,value}
>> pair to command line if argument is not already present.
>>
>> == Version 1 ==
>>
>> A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple
>> processors in the crash kernel.
>>
>> To do this safely the crash kernel needs to know which CPU was the 1st
>> kernel BSP (bootstrap processor) so that the crash kernel will NOT send
>> the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel
>> BSP, some systems may reset or hang.
>>
>> The EFI spec doesn't require that any particular processor is chosen
>> as the BSP and the CPU (and its apic id) can change from one boot to
>> the next. Hence automating the selection of CPU to disable if the
>> system would panic is desired.
>>
>> This patch updates the kdumpctl script to get the "initial apicid"
>> of CPU 0 in the first kernel and will pass this as the
>> "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly
>> set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.
>>
>> CPU 0 is chosen as it is the processor thats execute the OS
>> initialization
>> code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)
>>
>> See associated Red Hat Bugzilla(s) for additional background material:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1059031
>> https://bugzilla.redhat.com/show_bug.cgi?id=980621
>> ---
>> kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
>> 1 file changed, 54 insertions(+), 7 deletions(-)
>
> Thanks Jerry. This version looks good to me.
>
> Can you please test the disable_cpu_apicid override functionality by
> specifying it /etc/sysconfig/kdump and make sure it is working.
>
> Acked-by: Vivek Goyal <vgoyal(a)redhat.com>
>
> Thanks
> Vivek
>
A. On a prototype system that exihibits the underlying problem w/ INIT
to the 1st kernel BSP causing a hang.
B. System running RHEL 7.0 snap 6 plus kernel w/ Daisuke's patch
C. Using the modified kdumpctl script I sent yesterday.
D. Processor w/ APIC ID == 0 was deconfigured, so BSP has APIC ID == 2.
1) ran five crash dumps injecting error (echo c > /proc/sysrq-trigger)
on random cpu successfully. crash kernel had nr_cpus=4.
Crash dumps were successful.
2) Then configured /etc/sysconf/kdump to specify disable_cpu_apicid=0.
Injected error on CPU 24. This time the crash kernel hung when
bringing other processors on line.
The second test shows the crash kernel was looking to avoid INIT
of APICID 0, not as it should of in the case of this system which
has BSP w/ initial apicid of 2. (note, in development of the
script I had an echo of the command line argument and tested
this case to verify that explicit override was honored.)
I used RHEL 7.0 as I had access to RHEL 7 kernel that had Daisuke's
patch applied (not sure about Fedora kernels in this respect.)
Both RHEL 7.0 and Fedora 20 had the same kdumpctl scripts prior
to my modifications.
Jerry
Thanks for your work, Jerry.
Vivek, do you plan to write configuration of nr_cpus in any document?
Increasing nr_cpus increases amount of memory consumption in 2nd kernel,
and particular kind of modules consumes memory in proportion to the number
of logical cpus or local apic. It's cumbersome to automate configuring
nr_cpus setting by script while estimating amount of memory. So for manual
setting, notes on nr_cpus should be documented anywhere.
--
Thanks.
HATAYAMA, Daisuke
10:25 p.m.
New subject: [PATCH v2] kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel
On Fri, Mar 14, 2014 at 06:58:55PM +0900, HATAYAMA Daisuke wrote:
[..]
Vivek, do you plan to write configuration of nr_cpus in any
document?
Increasing nr_cpus increases amount of memory consumption in 2nd kernel,
and particular kind of modules consumes memory in proportion to the number
of logical cpus or local apic. It's cumbersome to automate configuring
nr_cpus setting by script while estimating amount of memory. So for manual
setting, notes on nr_cpus should be documented anywhere.
I agree that we should document nr_cpus and its impact on kdump. Possibly
we can put few lines in kexec-kdump-howto.txt. Would you like to send
a patch. We can also talk of disable_apic_id usage in same paragraph.
Also I had a question. One reason you wanted to bring up multiple cpus
in second kernel so that one can do compression in parallel on large
machines.
How to use that functionality.
Thanks
Vivek
3:38 a.m.
On 02/20/14 at 06:09pm, Jerry Hoemann wrote:
== Version 2 ==
+#
+# This function returns the "initial apicid" of the
+# boot cpu (cpu 0) if present.
+#
+function get_bootcpu_initial_apicid()
+{
+ awk ' \
+ BEGIN { CPU = "-1"; } \
+ $1=="processor" && $2==":" { CPU = $NF; } \
+ CPU=="0" && /initial apicid/ { print $NF; } \
+ ' \
+ /proc/cpuinfo
Hi Jerry,
How does it go with virtual machine? I didn't find the "initial apicid"
on my kvm guest.
Baoquan
Thanks
+}
+
+#
8:22 p.m.
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 ==
>
> +#
> +# This function returns the "initial apicid" of the
> +# boot cpu (cpu 0) if present.
> +#
> +function get_bootcpu_initial_apicid()
> +{
> + awk ' \
> + BEGIN { CPU = "-1"; } \
> + $1=="processor" && $2==":" { CPU = $NF; } \
> + CPU=="0" && /initial apicid/ { print $NF; } \
> + ' \
> + /proc/cpuinfo
Hi Jerry,
How does it go with virtual machine? I didn't find the "initial apicid"
on my kvm guest.
Baoquan
Thanks
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.
Howerver, this does mean that a kvm instance might still have difficultly
specifying nr_cpus > 1 for crash kernel.
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.
Thanks for your feedback.
Jerry
--
----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett-Packard
3404 E Harmony Rd. MS 57 phone: (970) 898-1022
Ft. Collins, CO 80528 FAX: (970) 898-XXXX
email: jerry.hoemann(a)hp.com
----------------------------------------------------------------------------
2:58 a.m.
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
>
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.
Howerver, this does mean that a kvm instance might still have difficultly
specifying nr_cpus > 1 for crash kernel.
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.
OK, this makes sense to me. Thanks Jerry.
Baoquan
THanks
11:33 a.m.
(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(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
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(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>
Link: http://lkml.kernel.org/r/5277D644.4090707@jp.fujitsu.com
Signed-off-by: Ingo Molnar <mingo(a)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
3:53 a.m.
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(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
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(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>
Link: http://lkml.kernel.org/r/5277D644.4090707@jp.fujitsu.com
Signed-off-by: Ingo Molnar <mingo(a)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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/kexec
3690
days inactive
3714
days old
9 comments
4 participants
participants (4)
-
Baoquan He -
HATAYAMA Daisuke -
Jerry Hoemann -
Vivek Goyal