* [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel
@ 2016-08-01 0:23 ` Zhou Wenjian
0 siblings, 0 replies; 8+ messages in thread
From: Zhou Wenjian @ 2016-08-01 0:23 UTC (permalink / raw)
To: linux-kernel; +Cc: kexec, bhe, dyoung, d.hatayama
v1->v2: change nr_cpus to maxcpus
SMP dump-capture kernel is useful to improve the performance of kdump in
some cases. So add the description of bringing up SMP dump-capture kernel.
Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
---
Documentation/kdump/kdump.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..c5762b7 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -394,6 +394,12 @@ Notes on loading the dump-capture kernel:
dump. Hence generally it is useful either to build a UP dump-capture
kernel or specify maxcpus=1 option while loading dump-capture kernel.
+* We should bring up a SMP dump-capture kernel if we intend to use multi-threads
+ programs with it, such as parallel dump feature of makedumpfile. Otherwise,
+ the multi-threads program may have a great performance degradation.
+ To bring up a SMP dump-capture kernel, we should specify maxcpus=[X] and
+ disable_cpu_apic=[Y] options while loading it.
+
* For s390x there are two kdump modes: If a ELF header is specified with
the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
is done on all other architectures. If no elfcorehdr= kernel parameter is
--
1.8.3.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel
@ 2016-08-01 0:23 ` Zhou Wenjian
0 siblings, 0 replies; 8+ messages in thread
From: Zhou Wenjian @ 2016-08-01 0:23 UTC (permalink / raw)
To: linux-kernel; +Cc: dyoung, d.hatayama, kexec, bhe
v1->v2: change nr_cpus to maxcpus
SMP dump-capture kernel is useful to improve the performance of kdump in
some cases. So add the description of bringing up SMP dump-capture kernel.
Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
---
Documentation/kdump/kdump.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..c5762b7 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -394,6 +394,12 @@ Notes on loading the dump-capture kernel:
dump. Hence generally it is useful either to build a UP dump-capture
kernel or specify maxcpus=1 option while loading dump-capture kernel.
+* We should bring up a SMP dump-capture kernel if we intend to use multi-threads
+ programs with it, such as parallel dump feature of makedumpfile. Otherwise,
+ the multi-threads program may have a great performance degradation.
+ To bring up a SMP dump-capture kernel, we should specify maxcpus=[X] and
+ disable_cpu_apic=[Y] options while loading it.
+
* For s390x there are two kdump modes: If a ELF header is specified with
the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
is done on all other architectures. If no elfcorehdr= kernel parameter is
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel
2016-08-01 0:23 ` Zhou Wenjian
@ 2016-08-02 7:46 ` Baoquan He
-1 siblings, 0 replies; 8+ messages in thread
From: Baoquan He @ 2016-08-02 7:46 UTC (permalink / raw)
To: Zhou Wenjian; +Cc: linux-kernel, kexec, dyoung, d.hatayama
Hi Wenjian,
On 08/01/16 at 08:23am, Zhou Wenjian wrote:
> v1->v2: change nr_cpus to maxcpus
>
> SMP dump-capture kernel is useful to improve the performance of kdump in
> some cases. So add the description of bringing up SMP dump-capture kernel.
>
> Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
Discussed with people, it could be better to adjust the
description about nr_cpus and maxcpus part. I think you can still
describe nr_cpus/maxcpus in patch 1/2, and keep parallel dumping part in
2/2.
Originally maxcpus=1 is used for all ARCHes. Later people found
nr_cpus=1 is better since nr_cpus decides the number of possible cpu
while maxcpus decides the max working cpu after system boot. So nr_cpus
can save memory because percpu will pre-allocate memory for each
possible cpu for hotplug. So on x86 nr_cpus is used because much memory
can be saved if possible cpu number is very large.
So you can mention that both maxcpus and nr_cpus can be used but nr_cpus
has advantage if it has been implemented in some ARCHes like x86_64. And
I guess you mush have tested parallel dumping feature with nr_cpus
specified, it makes sense to tell people with the real situation.
Thanks
Baoquan
> ---
> Documentation/kdump/kdump.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 88ff63d..c5762b7 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -394,6 +394,12 @@ Notes on loading the dump-capture kernel:
> dump. Hence generally it is useful either to build a UP dump-capture
> kernel or specify maxcpus=1 option while loading dump-capture kernel.
>
> +* We should bring up a SMP dump-capture kernel if we intend to use multi-threads
> + programs with it, such as parallel dump feature of makedumpfile. Otherwise,
> + the multi-threads program may have a great performance degradation.
> + To bring up a SMP dump-capture kernel, we should specify maxcpus=[X] and
> + disable_cpu_apic=[Y] options while loading it.
> +
> * For s390x there are two kdump modes: If a ELF header is specified with
> the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
> is done on all other architectures. If no elfcorehdr= kernel parameter is
> --
> 1.8.3.1
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel
@ 2016-08-02 7:46 ` Baoquan He
0 siblings, 0 replies; 8+ messages in thread
From: Baoquan He @ 2016-08-02 7:46 UTC (permalink / raw)
To: Zhou Wenjian; +Cc: dyoung, d.hatayama, kexec, linux-kernel
Hi Wenjian,
On 08/01/16 at 08:23am, Zhou Wenjian wrote:
> v1->v2: change nr_cpus to maxcpus
>
> SMP dump-capture kernel is useful to improve the performance of kdump in
> some cases. So add the description of bringing up SMP dump-capture kernel.
>
> Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
Discussed with people, it could be better to adjust the
description about nr_cpus and maxcpus part. I think you can still
describe nr_cpus/maxcpus in patch 1/2, and keep parallel dumping part in
2/2.
Originally maxcpus=1 is used for all ARCHes. Later people found
nr_cpus=1 is better since nr_cpus decides the number of possible cpu
while maxcpus decides the max working cpu after system boot. So nr_cpus
can save memory because percpu will pre-allocate memory for each
possible cpu for hotplug. So on x86 nr_cpus is used because much memory
can be saved if possible cpu number is very large.
So you can mention that both maxcpus and nr_cpus can be used but nr_cpus
has advantage if it has been implemented in some ARCHes like x86_64. And
I guess you mush have tested parallel dumping feature with nr_cpus
specified, it makes sense to tell people with the real situation.
Thanks
Baoquan
> ---
> Documentation/kdump/kdump.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 88ff63d..c5762b7 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -394,6 +394,12 @@ Notes on loading the dump-capture kernel:
> dump. Hence generally it is useful either to build a UP dump-capture
> kernel or specify maxcpus=1 option while loading dump-capture kernel.
>
> +* We should bring up a SMP dump-capture kernel if we intend to use multi-threads
> + programs with it, such as parallel dump feature of makedumpfile. Otherwise,
> + the multi-threads program may have a great performance degradation.
> + To bring up a SMP dump-capture kernel, we should specify maxcpus=[X] and
> + disable_cpu_apic=[Y] options while loading it.
> +
> * For s390x there are two kdump modes: If a ELF header is specified with
> the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
> is done on all other architectures. If no elfcorehdr= kernel parameter is
> --
> 1.8.3.1
>
>
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel
2016-08-02 7:46 ` Baoquan He
@ 2016-08-02 8:49 ` "Zhou, Wenjian/周文剑"
-1 siblings, 0 replies; 8+ messages in thread
From: "Zhou, Wenjian/周文剑" @ 2016-08-02 8:49 UTC (permalink / raw)
To: Baoquan He; +Cc: linux-kernel, kexec, dyoung, d.hatayama
Hi Baoquan,
On 08/02/2016 03:46 PM, Baoquan He wrote:
> Hi Wenjian,
>
> On 08/01/16 at 08:23am, Zhou Wenjian wrote:
>> v1->v2: change nr_cpus to maxcpus
>>
>> SMP dump-capture kernel is useful to improve the performance of kdump in
>> some cases. So add the description of bringing up SMP dump-capture kernel.
>>
>> Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
>
> Discussed with people, it could be better to adjust the
> description about nr_cpus and maxcpus part. I think you can still
> describe nr_cpus/maxcpus in patch 1/2, and keep parallel dumping part in
> 2/2.
>
> Originally maxcpus=1 is used for all ARCHes. Later people found
> nr_cpus=1 is better since nr_cpus decides the number of possible cpu
> while maxcpus decides the max working cpu after system boot. So nr_cpus
> can save memory because percpu will pre-allocate memory for each
> possible cpu for hotplug. So on x86 nr_cpus is used because much memory
> can be saved if possible cpu number is very large.
>
> So you can mention that both maxcpus and nr_cpus can be used but nr_cpus
> has advantage if it has been implemented in some ARCHes like x86_64. And
> I guess you mush have tested parallel dumping feature with nr_cpus
> specified, it makes sense to tell people with the real situation.
>
I think it is better to describe the difference in somewhere else.
Maybe, it's a good choice which just replace maxcpus by maxcpus/nr_cpus.
Then user can choose maxcpus or nr_cpus.
What do you think about it?
--
Thanks
Zhou
> Thanks
> Baoquan
>
>> ---
>> Documentation/kdump/kdump.txt | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>> index 88ff63d..c5762b7 100644
>> --- a/Documentation/kdump/kdump.txt
>> +++ b/Documentation/kdump/kdump.txt
>> @@ -394,6 +394,12 @@ Notes on loading the dump-capture kernel:
>> dump. Hence generally it is useful either to build a UP dump-capture
>> kernel or specify maxcpus=1 option while loading dump-capture kernel.
>>
>> +* We should bring up a SMP dump-capture kernel if we intend to use multi-threads
>> + programs with it, such as parallel dump feature of makedumpfile. Otherwise,
>> + the multi-threads program may have a great performance degradation.
>> + To bring up a SMP dump-capture kernel, we should specify maxcpus=[X] and
>> + disable_cpu_apic=[Y] options while loading it.
>> +
>> * For s390x there are two kdump modes: If a ELF header is specified with
>> the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
>> is done on all other architectures. If no elfcorehdr= kernel parameter is
>> --
>> 1.8.3.1
>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel
@ 2016-08-02 8:49 ` "Zhou, Wenjian/周文剑"
0 siblings, 0 replies; 8+ messages in thread
From: "Zhou, Wenjian/周文剑" @ 2016-08-02 8:49 UTC (permalink / raw)
To: Baoquan He; +Cc: dyoung, d.hatayama, kexec, linux-kernel
Hi Baoquan,
On 08/02/2016 03:46 PM, Baoquan He wrote:
> Hi Wenjian,
>
> On 08/01/16 at 08:23am, Zhou Wenjian wrote:
>> v1->v2: change nr_cpus to maxcpus
>>
>> SMP dump-capture kernel is useful to improve the performance of kdump in
>> some cases. So add the description of bringing up SMP dump-capture kernel.
>>
>> Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
>
> Discussed with people, it could be better to adjust the
> description about nr_cpus and maxcpus part. I think you can still
> describe nr_cpus/maxcpus in patch 1/2, and keep parallel dumping part in
> 2/2.
>
> Originally maxcpus=1 is used for all ARCHes. Later people found
> nr_cpus=1 is better since nr_cpus decides the number of possible cpu
> while maxcpus decides the max working cpu after system boot. So nr_cpus
> can save memory because percpu will pre-allocate memory for each
> possible cpu for hotplug. So on x86 nr_cpus is used because much memory
> can be saved if possible cpu number is very large.
>
> So you can mention that both maxcpus and nr_cpus can be used but nr_cpus
> has advantage if it has been implemented in some ARCHes like x86_64. And
> I guess you mush have tested parallel dumping feature with nr_cpus
> specified, it makes sense to tell people with the real situation.
>
I think it is better to describe the difference in somewhere else.
Maybe, it's a good choice which just replace maxcpus by maxcpus/nr_cpus.
Then user can choose maxcpus or nr_cpus.
What do you think about it?
--
Thanks
Zhou
> Thanks
> Baoquan
>
>> ---
>> Documentation/kdump/kdump.txt | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>> index 88ff63d..c5762b7 100644
>> --- a/Documentation/kdump/kdump.txt
>> +++ b/Documentation/kdump/kdump.txt
>> @@ -394,6 +394,12 @@ Notes on loading the dump-capture kernel:
>> dump. Hence generally it is useful either to build a UP dump-capture
>> kernel or specify maxcpus=1 option while loading dump-capture kernel.
>>
>> +* We should bring up a SMP dump-capture kernel if we intend to use multi-threads
>> + programs with it, such as parallel dump feature of makedumpfile. Otherwise,
>> + the multi-threads program may have a great performance degradation.
>> + To bring up a SMP dump-capture kernel, we should specify maxcpus=[X] and
>> + disable_cpu_apic=[Y] options while loading it.
>> +
>> * For s390x there are two kdump modes: If a ELF header is specified with
>> the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
>> is done on all other architectures. If no elfcorehdr= kernel parameter is
>> --
>> 1.8.3.1
>>
>>
>>
>
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel
2016-08-02 8:49 ` "Zhou, Wenjian/周文剑"
@ 2016-08-02 14:09 ` Baoquan He
-1 siblings, 0 replies; 8+ messages in thread
From: Baoquan He @ 2016-08-02 14:09 UTC (permalink / raw)
To: "Zhou, Wenjian/周文剑"
Cc: linux-kernel, kexec, dyoung, d.hatayama
On 08/02/16 at 04:49pm, "Zhou, Wenjian/周文剑" wrote:
> Hi Baoquan,
>
> On 08/02/2016 03:46 PM, Baoquan He wrote:
> >Hi Wenjian,
> >
> >On 08/01/16 at 08:23am, Zhou Wenjian wrote:
> >>v1->v2: change nr_cpus to maxcpus
> >>
> >>SMP dump-capture kernel is useful to improve the performance of kdump in
> >>some cases. So add the description of bringing up SMP dump-capture kernel.
> >>
> >>Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
> >
> >Discussed with people, it could be better to adjust the
> >description about nr_cpus and maxcpus part. I think you can still
> >describe nr_cpus/maxcpus in patch 1/2, and keep parallel dumping part in
> >2/2.
> >
> >Originally maxcpus=1 is used for all ARCHes. Later people found
> >nr_cpus=1 is better since nr_cpus decides the number of possible cpu
> >while maxcpus decides the max working cpu after system boot. So nr_cpus
> >can save memory because percpu will pre-allocate memory for each
> >possible cpu for hotplug. So on x86 nr_cpus is used because much memory
> >can be saved if possible cpu number is very large.
> >
> >So you can mention that both maxcpus and nr_cpus can be used but nr_cpus
> >has advantage if it has been implemented in some ARCHes like x86_64. And
> >I guess you mush have tested parallel dumping feature with nr_cpus
> >specified, it makes sense to tell people with the real situation.
> >
>
> I think it is better to describe the difference in somewhere else.
> Maybe, it's a good choice which just replace maxcpus by maxcpus/nr_cpus.
> Then user can choose maxcpus or nr_cpus.
> What do you think about it?
Putting it in kdump.txt could be better. nr_cpus/maxcpus are normal
kernel options, the reason we mentioned them here is crashkernel memory
is usually limited, we have to try our best to save memory. So if
nr_cpus is available on some ARCHes, we should use it. On x86 nr_cpus=1
has been taken for kdump kernel for a very long time. I think letting
people know below things would be good:
~~~~~~~~~~
Firslty both maxcpus and nr_cpus can be used for kdump kernel to specify
number of allowed cpu.
maxcpus only specify the number of available cpu, while nr_cpus will
specify the number of possible cpu which is necessary for hotplug.
nr_cpus can be used to limit the amount of percpu memory pre-allocation.
And now you just test parallel dumping feature on x86, or more
specifically on x86_64.
~~~~~~~~~~~
Thanks
Baoquan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel
@ 2016-08-02 14:09 ` Baoquan He
0 siblings, 0 replies; 8+ messages in thread
From: Baoquan He @ 2016-08-02 14:09 UTC (permalink / raw)
To: "Zhou, Wenjian/周文剑"
Cc: dyoung, d.hatayama, kexec, linux-kernel
On 08/02/16 at 04:49pm, "Zhou, Wenjian/周文剑" wrote:
> Hi Baoquan,
>
> On 08/02/2016 03:46 PM, Baoquan He wrote:
> >Hi Wenjian,
> >
> >On 08/01/16 at 08:23am, Zhou Wenjian wrote:
> >>v1->v2: change nr_cpus to maxcpus
> >>
> >>SMP dump-capture kernel is useful to improve the performance of kdump in
> >>some cases. So add the description of bringing up SMP dump-capture kernel.
> >>
> >>Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
> >
> >Discussed with people, it could be better to adjust the
> >description about nr_cpus and maxcpus part. I think you can still
> >describe nr_cpus/maxcpus in patch 1/2, and keep parallel dumping part in
> >2/2.
> >
> >Originally maxcpus=1 is used for all ARCHes. Later people found
> >nr_cpus=1 is better since nr_cpus decides the number of possible cpu
> >while maxcpus decides the max working cpu after system boot. So nr_cpus
> >can save memory because percpu will pre-allocate memory for each
> >possible cpu for hotplug. So on x86 nr_cpus is used because much memory
> >can be saved if possible cpu number is very large.
> >
> >So you can mention that both maxcpus and nr_cpus can be used but nr_cpus
> >has advantage if it has been implemented in some ARCHes like x86_64. And
> >I guess you mush have tested parallel dumping feature with nr_cpus
> >specified, it makes sense to tell people with the real situation.
> >
>
> I think it is better to describe the difference in somewhere else.
> Maybe, it's a good choice which just replace maxcpus by maxcpus/nr_cpus.
> Then user can choose maxcpus or nr_cpus.
> What do you think about it?
Putting it in kdump.txt could be better. nr_cpus/maxcpus are normal
kernel options, the reason we mentioned them here is crashkernel memory
is usually limited, we have to try our best to save memory. So if
nr_cpus is available on some ARCHes, we should use it. On x86 nr_cpus=1
has been taken for kdump kernel for a very long time. I think letting
people know below things would be good:
~~~~~~~~~~
Firslty both maxcpus and nr_cpus can be used for kdump kernel to specify
number of allowed cpu.
maxcpus only specify the number of available cpu, while nr_cpus will
specify the number of possible cpu which is necessary for hotplug.
nr_cpus can be used to limit the amount of percpu memory pre-allocation.
And now you just test parallel dumping feature on x86, or more
specifically on x86_64.
~~~~~~~~~~~
Thanks
Baoquan
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-08-02 14:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-01 0:23 [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel Zhou Wenjian
2016-08-01 0:23 ` Zhou Wenjian
2016-08-02 7:46 ` Baoquan He
2016-08-02 7:46 ` Baoquan He
2016-08-02 8:49 ` "Zhou, Wenjian/周文剑"
2016-08-02 8:49 ` "Zhou, Wenjian/周文剑"
2016-08-02 14:09 ` Baoquan He
2016-08-02 14:09 ` Baoquan He
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.