[PATCH v9 0/2] update the doc of kdump

[PATCH v9 0/2] update the doc of kdump

[Zhou Wenjian]

v8->v9: rearrange the patch.
        it won't fix typo which original exists.
        those should be fixed in other patch, which I'll post later.
v7->v8: fix "a SMP kernel" to "an SMP kernel" and replace "\" with "/"
v6->v7: fix typo
v5->v6: replace "we" with "you"
v4->v5: move change log to cover letter
v3->v4: update the description of bring up SMP dump-capture kernel
v2->v3: add description of nr_cpus.
v1->v2: change nr_cpus to maxcpus

Zhou Wenjian (2):
  Documentation: kdump: remind user of nr_cpus
  Documentation: kdump: add description of enable multi-cpus support

 Documentation/kdump/kdump.txt | 9 +++++++++
 1 file changed, 9 insertions(+)

-- 
1.8.3.1

[PATCH v9 0/2] update the doc of kdump

[Zhou Wenjian]

v8->v9: rearrange the patch.
        it won't fix typo which original exists.
        those should be fixed in other patch, which I'll post later.
v7->v8: fix "a SMP kernel" to "an SMP kernel" and replace "\" with "/"
v6->v7: fix typo
v5->v6: replace "we" with "you"
v4->v5: move change log to cover letter
v3->v4: update the description of bring up SMP dump-capture kernel
v2->v3: add description of nr_cpus.
v1->v2: change nr_cpus to maxcpus

Zhou Wenjian (2):
  Documentation: kdump: remind user of nr_cpus
  Documentation: kdump: add description of enable multi-cpus support

 Documentation/kdump/kdump.txt | 9 +++++++++
 1 file changed, 9 insertions(+)

-- 
1.8.3.1




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Zhou Wenjian]

nr_cpus can help to save memory. So we should remind user of it.

Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Xunlei Pang <xpang@redhat.com>
---
 Documentation/kdump/kdump.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..d900080 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  Note, though maxcpus always works, you should replace it by nr_cpus to
+  save memory if supported by the current ARCH, such as x86.
 
 * 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
-- 
1.8.3.1

[PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Zhou Wenjian]

nr_cpus can help to save memory. So we should remind user of it.

Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Xunlei Pang <xpang@redhat.com>
---
 Documentation/kdump/kdump.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..d900080 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  Note, though maxcpus always works, you should replace it by nr_cpus to
+  save memory if supported by the current ARCH, such as x86.
 
 * 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
-- 
1.8.3.1




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v9 2/2] Documentation: kdump: add description of enable multi-cpus support

[Zhou Wenjian]

multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.

Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Xunlei Pang <xpang@redhat.com>
---
 Documentation/kdump/kdump.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index d900080..31e6b88 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
   Note, though maxcpus always works, you should replace it by nr_cpus to
   save memory if supported by the current ARCH, such as x86.
 
+* You should enable multi-cpu support in dump-capture kernel if you intend
+  to use multi-thread programs with it, such as parallel dump feature of
+  makedumpfile. Otherwise, the multi-thread program may have a great
+  performance degradation. To enable multi-cpu support, you should bring up an
+  SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
+  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

[PATCH v9 2/2] Documentation: kdump: add description of enable multi-cpus support

[Zhou Wenjian]

multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.

Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Xunlei Pang <xpang@redhat.com>
---
 Documentation/kdump/kdump.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index d900080..31e6b88 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
   Note, though maxcpus always works, you should replace it by nr_cpus to
   save memory if supported by the current ARCH, such as x86.
 
+* You should enable multi-cpu support in dump-capture kernel if you intend
+  to use multi-thread programs with it, such as parallel dump feature of
+  makedumpfile. Otherwise, the multi-thread program may have a great
+  performance degradation. To enable multi-cpu support, you should bring up an
+  SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
+  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

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Jonathan Corbet]

On Thu, 18 Aug 2016 11:11:46 +0800
Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com> wrote:

Thank you for working to improve the documentation!

>  * We generally don' have to bring up a SMP kernel just to capture the
>    dump. Hence generally it is useful either to build a UP dump-capture
>    kernel or specify maxcpus=1 option while loading dump-capture kernel.
> +  Note, though maxcpus always works, you should replace it by nr_cpus to
> +  save memory if supported by the current ARCH, such as x86.

So, IMHO, this seems like the wrong place for this.  I've just spent a bit
of time staring at kernel-parameters.txt, and there is no way for a
clueless user like me to know what the difference is between maxcpus= and
nr_cpus= would be.  A far better patch would be to update the
documentation there to make that clear.  Any chance you would be willing
to do that?

Then, rather than tacking an "ignore what you just read" note into
kdump.txt, it could maybe be rewritten to simply say what users should do?

Thanks,

jon

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Jonathan Corbet]

On Thu, 18 Aug 2016 11:11:46 +0800
Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com> wrote:

Thank you for working to improve the documentation!

>  * We generally don' have to bring up a SMP kernel just to capture the
>    dump. Hence generally it is useful either to build a UP dump-capture
>    kernel or specify maxcpus=1 option while loading dump-capture kernel.
> +  Note, though maxcpus always works, you should replace it by nr_cpus to
> +  save memory if supported by the current ARCH, such as x86.

So, IMHO, this seems like the wrong place for this.  I've just spent a bit
of time staring at kernel-parameters.txt, and there is no way for a
clueless user like me to know what the difference is between maxcpus= and
nr_cpus= would be.  A far better patch would be to update the
documentation there to make that clear.  Any chance you would be willing
to do that?

Then, rather than tacking an "ignore what you just read" note into
kdump.txt, it could maybe be rewritten to simply say what users should do?

Thanks,

jon

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

["Zhou, Wenjian/周文剑"]

Hi Jonathan,

Thanks for your reply.

On 08/19/2016 01:18 AM, Jonathan Corbet wrote:
> On Thu, 18 Aug 2016 11:11:46 +0800
> Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com> wrote:
>
> Thank you for working to improve the documentation!
>
>>   * We generally don' have to bring up a SMP kernel just to capture the
>>     dump. Hence generally it is useful either to build a UP dump-capture
>>     kernel or specify maxcpus=1 option while loading dump-capture kernel.
>> +  Note, though maxcpus always works, you should replace it by nr_cpus to
>> +  save memory if supported by the current ARCH, such as x86.
>
> So, IMHO, this seems like the wrong place for this.  I've just spent a bit
> of time staring at kernel-parameters.txt, and there is no way for a
> clueless user like me to know what the difference is between maxcpus= and
> nr_cpus= would be.  A far better patch would be to update the
> documentation there to make that clear.  Any chance you would be willing
> to do that?
>
> Then, rather than tacking an "ignore what you just read" note into
> kdump.txt, it could maybe be rewritten to simply say what users should do?
>

I was also confused by maxcpus and nr_cpus before writing this patch.
I think it is a good choice to describe it in kernel-parameters.txt.

Then, only two things need to be done I think.
One is move the above description to maxcpus= in kernel-parameters.txt.
And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.

How do you think?

-- 
Thanks
Zhou

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

["Zhou, Wenjian/周文剑"]

Hi Jonathan,

Thanks for your reply.

On 08/19/2016 01:18 AM, Jonathan Corbet wrote:
> On Thu, 18 Aug 2016 11:11:46 +0800
> Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com> wrote:
>
> Thank you for working to improve the documentation!
>
>>   * We generally don' have to bring up a SMP kernel just to capture the
>>     dump. Hence generally it is useful either to build a UP dump-capture
>>     kernel or specify maxcpus=1 option while loading dump-capture kernel.
>> +  Note, though maxcpus always works, you should replace it by nr_cpus to
>> +  save memory if supported by the current ARCH, such as x86.
>
> So, IMHO, this seems like the wrong place for this.  I've just spent a bit
> of time staring at kernel-parameters.txt, and there is no way for a
> clueless user like me to know what the difference is between maxcpus= and
> nr_cpus= would be.  A far better patch would be to update the
> documentation there to make that clear.  Any chance you would be willing
> to do that?
>
> Then, rather than tacking an "ignore what you just read" note into
> kdump.txt, it could maybe be rewritten to simply say what users should do?
>

I was also confused by maxcpus and nr_cpus before writing this patch.
I think it is a good choice to describe it in kernel-parameters.txt.

Then, only two things need to be done I think.
One is move the above description to maxcpus= in kernel-parameters.txt.
And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.

How do you think?

-- 
Thanks
Zhou



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Jonathan Corbet]

On Fri, 19 Aug 2016 08:33:21 +0800
"Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:

> I was also confused by maxcpus and nr_cpus before writing this patch.
> I think it is a good choice to describe it in kernel-parameters.txt.
> 
> Then, only two things need to be done I think.
> One is move the above description to maxcpus= in kernel-parameters.txt.
> And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> 
> How do you think?

That is not quite what I had in mind, sorry.  What I would really like to
see in kernel-parameters.txt is an explanation of how those two parameters
differ - what do they do differently and how should a user choose one over
the other?  What we have now offers no guidance in that matter.

I suspect that may be a bit more than you had signed up to do.  As an
intermediate step, how about this: rather than tacking on those lines in
kdump.txt, rewrite that paragraph to simply say what the reader should
use.  If nr_cpus is good for everybody, just say that, but your previous
patch suggests that the situation isn't quite that simple?

Thanks,

jon

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Jonathan Corbet]

On Fri, 19 Aug 2016 08:33:21 +0800
"Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:

> I was also confused by maxcpus and nr_cpus before writing this patch.
> I think it is a good choice to describe it in kernel-parameters.txt.
> 
> Then, only two things need to be done I think.
> One is move the above description to maxcpus= in kernel-parameters.txt.
> And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> 
> How do you think?

That is not quite what I had in mind, sorry.  What I would really like to
see in kernel-parameters.txt is an explanation of how those two parameters
differ - what do they do differently and how should a user choose one over
the other?  What we have now offers no guidance in that matter.

I suspect that may be a bit more than you had signed up to do.  As an
intermediate step, how about this: rather than tacking on those lines in
kdump.txt, rewrite that paragraph to simply say what the reader should
use.  If nr_cpus is good for everybody, just say that, but your previous
patch suggests that the situation isn't quite that simple?

Thanks,

jon

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

["Zhou, Wenjian/周文剑"]

On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> On Fri, 19 Aug 2016 08:33:21 +0800
> "Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:
>
>> I was also confused by maxcpus and nr_cpus before writing this patch.
>> I think it is a good choice to describe it in kernel-parameters.txt.
>>
>> Then, only two things need to be done I think.
>> One is move the above description to maxcpus= in kernel-parameters.txt.
>> And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
>>
>> How do you think?
>
> That is not quite what I had in mind, sorry.  What I would really like to
> see in kernel-parameters.txt is an explanation of how those two parameters
> differ - what do they do differently and how should a user choose one over
> the other?  What we have now offers no guidance in that matter.
>

I thought about it. I think user may not need this.
What user really want to know is how to choose.
And it is also not a hard work. If nr_cpus is not supported by the ARCH, use maxcpus.
Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be supported
by some ARCHes.

I think it may be why the author didn't write too much description of it.

> I suspect that may be a bit more than you had signed up to do.  As an
> intermediate step, how about this: rather than tacking on those lines in
> kdump.txt, rewrite that paragraph to simply say what the reader should
> use.  If nr_cpus is good for everybody, just say that, but your previous
> patch suggests that the situation isn't quite that simple?
>

Actually, if nr_cpus always usable, there won't be these discussions.


-- 
Thanks
Zhou

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

["Zhou, Wenjian/周文剑"]

On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> On Fri, 19 Aug 2016 08:33:21 +0800
> "Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:
>
>> I was also confused by maxcpus and nr_cpus before writing this patch.
>> I think it is a good choice to describe it in kernel-parameters.txt.
>>
>> Then, only two things need to be done I think.
>> One is move the above description to maxcpus= in kernel-parameters.txt.
>> And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
>>
>> How do you think?
>
> That is not quite what I had in mind, sorry.  What I would really like to
> see in kernel-parameters.txt is an explanation of how those two parameters
> differ - what do they do differently and how should a user choose one over
> the other?  What we have now offers no guidance in that matter.
>

I thought about it. I think user may not need this.
What user really want to know is how to choose.
And it is also not a hard work. If nr_cpus is not supported by the ARCH, use maxcpus.
Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be supported
by some ARCHes.

I think it may be why the author didn't write too much description of it.

> I suspect that may be a bit more than you had signed up to do.  As an
> intermediate step, how about this: rather than tacking on those lines in
> kdump.txt, rewrite that paragraph to simply say what the reader should
> use.  If nr_cpus is good for everybody, just say that, but your previous
> patch suggests that the situation isn't quite that simple?
>

Actually, if nr_cpus always usable, there won't be these discussions.


-- 
Thanks
Zhou



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >On Fri, 19 Aug 2016 08:33:21 +0800
> >"Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:
> >
> >>I was also confused by maxcpus and nr_cpus before writing this patch.
> >>I think it is a good choice to describe it in kernel-parameters.txt.
> >>
> >>Then, only two things need to be done I think.
> >>One is move the above description to maxcpus= in kernel-parameters.txt.
> >>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> >>
> >>How do you think?
> >
> >That is not quite what I had in mind, sorry.  What I would really like to
> >see in kernel-parameters.txt is an explanation of how those two parameters
> >differ - what do they do differently and how should a user choose one over
> >the other?  What we have now offers no guidance in that matter.
> >
> 
> I thought about it. I think user may not need this.
> What user really want to know is how to choose.
> And it is also not a hard work. If nr_cpus is not supported by the ARCH, use maxcpus.
> Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be supported
> by some ARCHes.

I think Jon is suggesting that a note can be added into
kernel-parameter.txt to tell what's the difference between nr_cpus and
max_cpus. I checked code and discussed within our kdump team, max_cpus
is used to limit how many 'present' cpus are allowed to be brought up
during system bootup, while nr_cpus is used to set the upper limit of
'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
plug, means during bootup you want to bring up 4 present cpus, but
later you could physically hot plug 4 others. Because of attribute of
some static percpu variables, we need pre-allocate memory for all
possible cpus though some of them may not be really used if no extra
cpu physically hot plugged after system bootup.

Hence for kdump kernel, people never want to do a cpu hot plug in there.
That's why we want to use nr_cpus to limit the number of possible cpu to
save memory. E.g still on my laptop, if I want to do a kdump, the number
of possible cpu is still 8, but you may want to use only 1 cpu to dump,
maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
is much better. While with specifying max_cpus=1, the number of possible
cpu is still 8. That's the reason. On x86_64 and s390, there's another
kernel para "possible_cpus=xx" which can be used to set possible cpus for
cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
I am not very sure why this is introduced, number of possible cpu is
decided by the min value of nr_cpus= and possible_cpus=.

nr_cpus and maxcpus might not be very clear to people which are
described in Documentation/kernel-parameters.txt.

Hi Jon, do you think change as below is OK to you?


>From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@redhat.com>
Date: Wed, 24 Aug 2016 11:14:34 +0800
Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
 and maxcpus

>From the old description people still can't get what's the exact
difference between nr_cpus and maxcpus. Especially in kdump kernel
nr_cpus is always suggested if it's implemented in the ARCH. The
reason is nr_cpus is used to limit the max number of possible cpu
in system, the sum of already plugged cpus and hot plug cpus can't
exceed its value. However maxcpus is used to limit how many cpus
are allowed to be brought up during bootup.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 Documentation/kernel-parameters.txt | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 46c030a..25d3b36 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			than or equal to this physical address is ignored.
 
 	maxcpus=	[SMP] Maximum number of processors that	an SMP kernel
-			should make use of.  maxcpus=n : n >= 0 limits the
-			kernel to using 'n' processors.  n=0 is a special case,
-			it is equivalent to "nosmp", which also disables
-			the IO APIC.
+			will bring up during bootup.  maxcpus=n : n >= 0 limits
+			the kernel to bring up 'n' processors. Surely after
+			bootup you can bring up the other plugged cpu by executing
+			"echo 1 > /sys/devices/system/cpu/cpuX/online". So maxcpus
+			only takes effect during system bootup.
+			While n=0 is a special case, it is equivalent to "nosmp",
+			which also disables the IO APIC.
 
 	max_loop=	[LOOP] The number of loop block devices that get
 	(loop.max_loop)	unconditionally pre-created at init time. The default
@@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 	nr_cpus=	[SMP] Maximum number of processors that	an SMP kernel
 			could support.  nr_cpus=n : n >= 1 limits the kernel to
-			supporting 'n' processors. Later in runtime you can not
-			use hotplug cpu feature to put more cpu back to online.
-			just like you compile the kernel NR_CPUS=n
+			support 'n' processors. It could be larger than the
+			number of already plugged CPU during bootup, later in
+			runtime you can physically add extra cpu until it reaches
+			n. So during boot up some boot time memory for per-cpu
+			variables need be pre-allocated for later physical cpu
+			hot plugging.
 
 	nr_uarts=	[SERIAL] maximum number of UARTs to be registered.
 
-- 
2.5.5

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >On Fri, 19 Aug 2016 08:33:21 +0800
> >"Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:
> >
> >>I was also confused by maxcpus and nr_cpus before writing this patch.
> >>I think it is a good choice to describe it in kernel-parameters.txt.
> >>
> >>Then, only two things need to be done I think.
> >>One is move the above description to maxcpus= in kernel-parameters.txt.
> >>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> >>
> >>How do you think?
> >
> >That is not quite what I had in mind, sorry.  What I would really like to
> >see in kernel-parameters.txt is an explanation of how those two parameters
> >differ - what do they do differently and how should a user choose one over
> >the other?  What we have now offers no guidance in that matter.
> >
> 
> I thought about it. I think user may not need this.
> What user really want to know is how to choose.
> And it is also not a hard work. If nr_cpus is not supported by the ARCH, use maxcpus.
> Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be supported
> by some ARCHes.

I think Jon is suggesting that a note can be added into
kernel-parameter.txt to tell what's the difference between nr_cpus and
max_cpus. I checked code and discussed within our kdump team, max_cpus
is used to limit how many 'present' cpus are allowed to be brought up
during system bootup, while nr_cpus is used to set the upper limit of
'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
plug, means during bootup you want to bring up 4 present cpus, but
later you could physically hot plug 4 others. Because of attribute of
some static percpu variables, we need pre-allocate memory for all
possible cpus though some of them may not be really used if no extra
cpu physically hot plugged after system bootup.

Hence for kdump kernel, people never want to do a cpu hot plug in there.
That's why we want to use nr_cpus to limit the number of possible cpu to
save memory. E.g still on my laptop, if I want to do a kdump, the number
of possible cpu is still 8, but you may want to use only 1 cpu to dump,
maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
is much better. While with specifying max_cpus=1, the number of possible
cpu is still 8. That's the reason. On x86_64 and s390, there's another
kernel para "possible_cpus=xx" which can be used to set possible cpus for
cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
I am not very sure why this is introduced, number of possible cpu is
decided by the min value of nr_cpus= and possible_cpus=.

nr_cpus and maxcpus might not be very clear to people which are
described in Documentation/kernel-parameters.txt.

Hi Jon, do you think change as below is OK to you?


From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@redhat.com>
Date: Wed, 24 Aug 2016 11:14:34 +0800
Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
 and maxcpus

From the old description people still can't get what's the exact
difference between nr_cpus and maxcpus. Especially in kdump kernel
nr_cpus is always suggested if it's implemented in the ARCH. The
reason is nr_cpus is used to limit the max number of possible cpu
in system, the sum of already plugged cpus and hot plug cpus can't
exceed its value. However maxcpus is used to limit how many cpus
are allowed to be brought up during bootup.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 Documentation/kernel-parameters.txt | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 46c030a..25d3b36 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			than or equal to this physical address is ignored.
 
 	maxcpus=	[SMP] Maximum number of processors that	an SMP kernel
-			should make use of.  maxcpus=n : n >= 0 limits the
-			kernel to using 'n' processors.  n=0 is a special case,
-			it is equivalent to "nosmp", which also disables
-			the IO APIC.
+			will bring up during bootup.  maxcpus=n : n >= 0 limits
+			the kernel to bring up 'n' processors. Surely after
+			bootup you can bring up the other plugged cpu by executing
+			"echo 1 > /sys/devices/system/cpu/cpuX/online". So maxcpus
+			only takes effect during system bootup.
+			While n=0 is a special case, it is equivalent to "nosmp",
+			which also disables the IO APIC.
 
 	max_loop=	[LOOP] The number of loop block devices that get
 	(loop.max_loop)	unconditionally pre-created at init time. The default
@@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 	nr_cpus=	[SMP] Maximum number of processors that	an SMP kernel
 			could support.  nr_cpus=n : n >= 1 limits the kernel to
-			supporting 'n' processors. Later in runtime you can not
-			use hotplug cpu feature to put more cpu back to online.
-			just like you compile the kernel NR_CPUS=n
+			support 'n' processors. It could be larger than the
+			number of already plugged CPU during bootup, later in
+			runtime you can physically add extra cpu until it reaches
+			n. So during boot up some boot time memory for per-cpu
+			variables need be pre-allocated for later physical cpu
+			hot plugging.
 
 	nr_uarts=	[SERIAL] maximum number of UARTs to be registered.
 
-- 
2.5.5


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Jonathan Corbet]

On Wed, 24 Aug 2016 13:06:45 +0800
Baoquan He <bhe@redhat.com> wrote:

> Hi Jon, do you think change as below is OK to you?

So nr_cpus is the maximum value, and maxcpus is the current number.
Figures.  No wonder the documentation is confusing...

Anyway, this is much more along the lines of what I was hoping for, yes;
I'll go ahead and apply it.  Many thanks for humoring me on this!

jon

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Jonathan Corbet]

On Wed, 24 Aug 2016 13:06:45 +0800
Baoquan He <bhe@redhat.com> wrote:

> Hi Jon, do you think change as below is OK to you?

So nr_cpus is the maximum value, and maxcpus is the current number.
Figures.  No wonder the documentation is confusing...

Anyway, this is much more along the lines of what I was hoping for, yes;
I'll go ahead and apply it.  Many thanks for humoring me on this!

jon

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

["Zhou, Wenjian/周文剑"]

Hi Baoquan,

Sorry, I misunderstood it before.
Thanks for your detailed explanation.

Hi Jon and Baoquan, I'm confused about how to adjust the kdump.txt.
Does the patch set v9 still OK?

-- 
Thanks
Zhou

On 08/24/2016 01:06 PM, Baoquan He wrote:
> On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
>> On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
>>> On Fri, 19 Aug 2016 08:33:21 +0800
>>> "Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:
>>>
>>>> I was also confused by maxcpus and nr_cpus before writing this patch.
>>>> I think it is a good choice to describe it in kernel-parameters.txt.
>>>>
>>>> Then, only two things need to be done I think.
>>>> One is move the above description to maxcpus= in kernel-parameters.txt.
>>>> And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
>>>>
>>>> How do you think?
>>>
>>> That is not quite what I had in mind, sorry.  What I would really like to
>>> see in kernel-parameters.txt is an explanation of how those two parameters
>>> differ - what do they do differently and how should a user choose one over
>>> the other?  What we have now offers no guidance in that matter.
>>>
>>
>> I thought about it. I think user may not need this.
>> What user really want to know is how to choose.
>> And it is also not a hard work. If nr_cpus is not supported by the ARCH, use maxcpus.
>> Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be supported
>> by some ARCHes.
>
> I think Jon is suggesting that a note can be added into
> kernel-parameter.txt to tell what's the difference between nr_cpus and
> max_cpus. I checked code and discussed within our kdump team, max_cpus
> is used to limit how many 'present' cpus are allowed to be brought up
> during system bootup, while nr_cpus is used to set the upper limit of
> 'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
> cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
> plug, means during bootup you want to bring up 4 present cpus, but
> later you could physically hot plug 4 others. Because of attribute of
> some static percpu variables, we need pre-allocate memory for all
> possible cpus though some of them may not be really used if no extra
> cpu physically hot plugged after system bootup.
>
> Hence for kdump kernel, people never want to do a cpu hot plug in there.
> That's why we want to use nr_cpus to limit the number of possible cpu to
> save memory. E.g still on my laptop, if I want to do a kdump, the number
> of possible cpu is still 8, but you may want to use only 1 cpu to dump,
> maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
> nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
> memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
> is much better. While with specifying max_cpus=1, the number of possible
> cpu is still 8. That's the reason. On x86_64 and s390, there's another
> kernel para "possible_cpus=xx" which can be used to set possible cpus for
> cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
> I am not very sure why this is introduced, number of possible cpu is
> decided by the min value of nr_cpus= and possible_cpus=.
>
> nr_cpus and maxcpus might not be very clear to people which are
> described in Documentation/kernel-parameters.txt.
>
> Hi Jon, do you think change as below is OK to you?
>
>
>  From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
> From: Baoquan He <bhe@redhat.com>
> Date: Wed, 24 Aug 2016 11:14:34 +0800
> Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
>   and maxcpus
>
>  From the old description people still can't get what's the exact
> difference between nr_cpus and maxcpus. Especially in kdump kernel
> nr_cpus is always suggested if it's implemented in the ARCH. The
> reason is nr_cpus is used to limit the max number of possible cpu
> in system, the sum of already plugged cpus and hot plug cpus can't
> exceed its value. However maxcpus is used to limit how many cpus
> are allowed to be brought up during bootup.
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
>   Documentation/kernel-parameters.txt | 20 +++++++++++++-------
>   1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 46c030a..25d3b36 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>   			than or equal to this physical address is ignored.
>
>   	maxcpus=	[SMP] Maximum number of processors that	an SMP kernel
> -			should make use of.  maxcpus=n : n >= 0 limits the
> -			kernel to using 'n' processors.  n=0 is a special case,
> -			it is equivalent to "nosmp", which also disables
> -			the IO APIC.
> +			will bring up during bootup.  maxcpus=n : n >= 0 limits
> +			the kernel to bring up 'n' processors. Surely after
> +			bootup you can bring up the other plugged cpu by executing
> +			"echo 1 > /sys/devices/system/cpu/cpuX/online". So maxcpus
> +			only takes effect during system bootup.
> +			While n=0 is a special case, it is equivalent to "nosmp",
> +			which also disables the IO APIC.
>
>   	max_loop=	[LOOP] The number of loop block devices that get
>   	(loop.max_loop)	unconditionally pre-created at init time. The default
> @@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>
>   	nr_cpus=	[SMP] Maximum number of processors that	an SMP kernel
>   			could support.  nr_cpus=n : n >= 1 limits the kernel to
> -			supporting 'n' processors. Later in runtime you can not
> -			use hotplug cpu feature to put more cpu back to online.
> -			just like you compile the kernel NR_CPUS=n
> +			support 'n' processors. It could be larger than the
> +			number of already plugged CPU during bootup, later in
> +			runtime you can physically add extra cpu until it reaches
> +			n. So during boot up some boot time memory for per-cpu
> +			variables need be pre-allocated for later physical cpu
> +			hot plugging.
>
>   	nr_uarts=	[SERIAL] maximum number of UARTs to be registered.
>
>

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

["Zhou, Wenjian/周文剑"]

Hi Baoquan,

Sorry, I misunderstood it before.
Thanks for your detailed explanation.

Hi Jon and Baoquan, I'm confused about how to adjust the kdump.txt.
Does the patch set v9 still OK?

-- 
Thanks
Zhou

On 08/24/2016 01:06 PM, Baoquan He wrote:
> On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
>> On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
>>> On Fri, 19 Aug 2016 08:33:21 +0800
>>> "Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:
>>>
>>>> I was also confused by maxcpus and nr_cpus before writing this patch.
>>>> I think it is a good choice to describe it in kernel-parameters.txt.
>>>>
>>>> Then, only two things need to be done I think.
>>>> One is move the above description to maxcpus= in kernel-parameters.txt.
>>>> And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
>>>>
>>>> How do you think?
>>>
>>> That is not quite what I had in mind, sorry.  What I would really like to
>>> see in kernel-parameters.txt is an explanation of how those two parameters
>>> differ - what do they do differently and how should a user choose one over
>>> the other?  What we have now offers no guidance in that matter.
>>>
>>
>> I thought about it. I think user may not need this.
>> What user really want to know is how to choose.
>> And it is also not a hard work. If nr_cpus is not supported by the ARCH, use maxcpus.
>> Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be supported
>> by some ARCHes.
>
> I think Jon is suggesting that a note can be added into
> kernel-parameter.txt to tell what's the difference between nr_cpus and
> max_cpus. I checked code and discussed within our kdump team, max_cpus
> is used to limit how many 'present' cpus are allowed to be brought up
> during system bootup, while nr_cpus is used to set the upper limit of
> 'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
> cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
> plug, means during bootup you want to bring up 4 present cpus, but
> later you could physically hot plug 4 others. Because of attribute of
> some static percpu variables, we need pre-allocate memory for all
> possible cpus though some of them may not be really used if no extra
> cpu physically hot plugged after system bootup.
>
> Hence for kdump kernel, people never want to do a cpu hot plug in there.
> That's why we want to use nr_cpus to limit the number of possible cpu to
> save memory. E.g still on my laptop, if I want to do a kdump, the number
> of possible cpu is still 8, but you may want to use only 1 cpu to dump,
> maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
> nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
> memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
> is much better. While with specifying max_cpus=1, the number of possible
> cpu is still 8. That's the reason. On x86_64 and s390, there's another
> kernel para "possible_cpus=xx" which can be used to set possible cpus for
> cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
> I am not very sure why this is introduced, number of possible cpu is
> decided by the min value of nr_cpus= and possible_cpus=.
>
> nr_cpus and maxcpus might not be very clear to people which are
> described in Documentation/kernel-parameters.txt.
>
> Hi Jon, do you think change as below is OK to you?
>
>
>  From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
> From: Baoquan He <bhe@redhat.com>
> Date: Wed, 24 Aug 2016 11:14:34 +0800
> Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
>   and maxcpus
>
>  From the old description people still can't get what's the exact
> difference between nr_cpus and maxcpus. Especially in kdump kernel
> nr_cpus is always suggested if it's implemented in the ARCH. The
> reason is nr_cpus is used to limit the max number of possible cpu
> in system, the sum of already plugged cpus and hot plug cpus can't
> exceed its value. However maxcpus is used to limit how many cpus
> are allowed to be brought up during bootup.
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
>   Documentation/kernel-parameters.txt | 20 +++++++++++++-------
>   1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 46c030a..25d3b36 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>   			than or equal to this physical address is ignored.
>
>   	maxcpus=	[SMP] Maximum number of processors that	an SMP kernel
> -			should make use of.  maxcpus=n : n >= 0 limits the
> -			kernel to using 'n' processors.  n=0 is a special case,
> -			it is equivalent to "nosmp", which also disables
> -			the IO APIC.
> +			will bring up during bootup.  maxcpus=n : n >= 0 limits
> +			the kernel to bring up 'n' processors. Surely after
> +			bootup you can bring up the other plugged cpu by executing
> +			"echo 1 > /sys/devices/system/cpu/cpuX/online". So maxcpus
> +			only takes effect during system bootup.
> +			While n=0 is a special case, it is equivalent to "nosmp",
> +			which also disables the IO APIC.
>
>   	max_loop=	[LOOP] The number of loop block devices that get
>   	(loop.max_loop)	unconditionally pre-created at init time. The default
> @@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>
>   	nr_cpus=	[SMP] Maximum number of processors that	an SMP kernel
>   			could support.  nr_cpus=n : n >= 1 limits the kernel to
> -			supporting 'n' processors. Later in runtime you can not
> -			use hotplug cpu feature to put more cpu back to online.
> -			just like you compile the kernel NR_CPUS=n
> +			support 'n' processors. It could be larger than the
> +			number of already plugged CPU during bootup, later in
> +			runtime you can physically add extra cpu until it reaches
> +			n. So during boot up some boot time memory for per-cpu
> +			variables need be pre-allocated for later physical cpu
> +			hot plugging.
>
>   	nr_uarts=	[SERIAL] maximum number of UARTs to be registered.
>
>



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/25/16 at 01:10pm, Jonathan Corbet wrote:
> On Wed, 24 Aug 2016 13:06:45 +0800
> Baoquan He <bhe@redhat.com> wrote:
> 
> > Hi Jon, do you think change as below is OK to you?
> 
> So nr_cpus is the maximum value, and maxcpus is the current number.
> Figures.  No wonder the documentation is confusing...

Yes. Thanks for reviewing this patchset.

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/25/16 at 01:10pm, Jonathan Corbet wrote:
> On Wed, 24 Aug 2016 13:06:45 +0800
> Baoquan He <bhe@redhat.com> wrote:
> 
> > Hi Jon, do you think change as below is OK to you?
> 
> So nr_cpus is the maximum value, and maxcpus is the current number.
> Figures.  No wonder the documentation is confusing...

Yes. Thanks for reviewing this patchset.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/26/16 at 08:45am, "Zhou, Wenjian/周文剑" wrote:
> Hi Baoquan,
> 
> Sorry, I misunderstood it before.
> Thanks for your detailed explanation.
> 
> Hi Jon and Baoquan, I'm confused about how to adjust the kdump.txt.
> Does the patch set v9 still OK?

Yeah, I think it's OK. Let's wait for Jon's feekback.

> 
> -- 
> Thanks
> Zhou
> 
> On 08/24/2016 01:06 PM, Baoquan He wrote:
> >On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> >>On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >>>On Fri, 19 Aug 2016 08:33:21 +0800
> >>>"Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:
> >>>
> >>>>I was also confused by maxcpus and nr_cpus before writing this patch.
> >>>>I think it is a good choice to describe it in kernel-parameters.txt.
> >>>>
> >>>>Then, only two things need to be done I think.
> >>>>One is move the above description to maxcpus= in kernel-parameters.txt.
> >>>>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> >>>>
> >>>>How do you think?
> >>>
> >>>That is not quite what I had in mind, sorry.  What I would really like to
> >>>see in kernel-parameters.txt is an explanation of how those two parameters
> >>>differ - what do they do differently and how should a user choose one over
> >>>the other?  What we have now offers no guidance in that matter.
> >>>
> >>
> >>I thought about it. I think user may not need this.
> >>What user really want to know is how to choose.
> >>And it is also not a hard work. If nr_cpus is not supported by the ARCH, use maxcpus.
> >>Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be supported
> >>by some ARCHes.
> >
> >I think Jon is suggesting that a note can be added into
> >kernel-parameter.txt to tell what's the difference between nr_cpus and
> >max_cpus. I checked code and discussed within our kdump team, max_cpus
> >is used to limit how many 'present' cpus are allowed to be brought up
> >during system bootup, while nr_cpus is used to set the upper limit of
> >'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
> >cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
> >plug, means during bootup you want to bring up 4 present cpus, but
> >later you could physically hot plug 4 others. Because of attribute of
> >some static percpu variables, we need pre-allocate memory for all
> >possible cpus though some of them may not be really used if no extra
> >cpu physically hot plugged after system bootup.
> >
> >Hence for kdump kernel, people never want to do a cpu hot plug in there.
> >That's why we want to use nr_cpus to limit the number of possible cpu to
> >save memory. E.g still on my laptop, if I want to do a kdump, the number
> >of possible cpu is still 8, but you may want to use only 1 cpu to dump,
> >maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
> >nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
> >memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
> >is much better. While with specifying max_cpus=1, the number of possible
> >cpu is still 8. That's the reason. On x86_64 and s390, there's another
> >kernel para "possible_cpus=xx" which can be used to set possible cpus for
> >cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
> >I am not very sure why this is introduced, number of possible cpu is
> >decided by the min value of nr_cpus= and possible_cpus=.
> >
> >nr_cpus and maxcpus might not be very clear to people which are
> >described in Documentation/kernel-parameters.txt.
> >
> >Hi Jon, do you think change as below is OK to you?
> >
> >
> > From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
> >From: Baoquan He <bhe@redhat.com>
> >Date: Wed, 24 Aug 2016 11:14:34 +0800
> >Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
> >  and maxcpus
> >
> > From the old description people still can't get what's the exact
> >difference between nr_cpus and maxcpus. Especially in kdump kernel
> >nr_cpus is always suggested if it's implemented in the ARCH. The
> >reason is nr_cpus is used to limit the max number of possible cpu
> >in system, the sum of already plugged cpus and hot plug cpus can't
> >exceed its value. However maxcpus is used to limit how many cpus
> >are allowed to be brought up during bootup.
> >
> >Signed-off-by: Baoquan He <bhe@redhat.com>
> >---
> >  Documentation/kernel-parameters.txt | 20 +++++++++++++-------
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> >
> >diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> >index 46c030a..25d3b36 100644
> >--- a/Documentation/kernel-parameters.txt
> >+++ b/Documentation/kernel-parameters.txt
> >@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> >  			than or equal to this physical address is ignored.
> >
> >  	maxcpus=	[SMP] Maximum number of processors that	an SMP kernel
> >-			should make use of.  maxcpus=n : n >= 0 limits the
> >-			kernel to using 'n' processors.  n=0 is a special case,
> >-			it is equivalent to "nosmp", which also disables
> >-			the IO APIC.
> >+			will bring up during bootup.  maxcpus=n : n >= 0 limits
> >+			the kernel to bring up 'n' processors. Surely after
> >+			bootup you can bring up the other plugged cpu by executing
> >+			"echo 1 > /sys/devices/system/cpu/cpuX/online". So maxcpus
> >+			only takes effect during system bootup.
> >+			While n=0 is a special case, it is equivalent to "nosmp",
> >+			which also disables the IO APIC.
> >
> >  	max_loop=	[LOOP] The number of loop block devices that get
> >  	(loop.max_loop)	unconditionally pre-created at init time. The default
> >@@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> >
> >  	nr_cpus=	[SMP] Maximum number of processors that	an SMP kernel
> >  			could support.  nr_cpus=n : n >= 1 limits the kernel to
> >-			supporting 'n' processors. Later in runtime you can not
> >-			use hotplug cpu feature to put more cpu back to online.
> >-			just like you compile the kernel NR_CPUS=n
> >+			support 'n' processors. It could be larger than the
> >+			number of already plugged CPU during bootup, later in
> >+			runtime you can physically add extra cpu until it reaches
> >+			n. So during boot up some boot time memory for per-cpu
> >+			variables need be pre-allocated for later physical cpu
> >+			hot plugging.
> >
> >  	nr_uarts=	[SERIAL] maximum number of UARTs to be registered.
> >
> >
> 
> 

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/26/16 at 08:45am, "Zhou, Wenjian/周文剑" wrote:
> Hi Baoquan,
> 
> Sorry, I misunderstood it before.
> Thanks for your detailed explanation.
> 
> Hi Jon and Baoquan, I'm confused about how to adjust the kdump.txt.
> Does the patch set v9 still OK?

Yeah, I think it's OK. Let's wait for Jon's feekback.

> 
> -- 
> Thanks
> Zhou
> 
> On 08/24/2016 01:06 PM, Baoquan He wrote:
> >On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> >>On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >>>On Fri, 19 Aug 2016 08:33:21 +0800
> >>>"Zhou, Wenjian/周文剑" <zhouwj-fnst@cn.fujitsu.com> wrote:
> >>>
> >>>>I was also confused by maxcpus and nr_cpus before writing this patch.
> >>>>I think it is a good choice to describe it in kernel-parameters.txt.
> >>>>
> >>>>Then, only two things need to be done I think.
> >>>>One is move the above description to maxcpus= in kernel-parameters.txt.
> >>>>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> >>>>
> >>>>How do you think?
> >>>
> >>>That is not quite what I had in mind, sorry.  What I would really like to
> >>>see in kernel-parameters.txt is an explanation of how those two parameters
> >>>differ - what do they do differently and how should a user choose one over
> >>>the other?  What we have now offers no guidance in that matter.
> >>>
> >>
> >>I thought about it. I think user may not need this.
> >>What user really want to know is how to choose.
> >>And it is also not a hard work. If nr_cpus is not supported by the ARCH, use maxcpus.
> >>Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be supported
> >>by some ARCHes.
> >
> >I think Jon is suggesting that a note can be added into
> >kernel-parameter.txt to tell what's the difference between nr_cpus and
> >max_cpus. I checked code and discussed within our kdump team, max_cpus
> >is used to limit how many 'present' cpus are allowed to be brought up
> >during system bootup, while nr_cpus is used to set the upper limit of
> >'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
> >cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
> >plug, means during bootup you want to bring up 4 present cpus, but
> >later you could physically hot plug 4 others. Because of attribute of
> >some static percpu variables, we need pre-allocate memory for all
> >possible cpus though some of them may not be really used if no extra
> >cpu physically hot plugged after system bootup.
> >
> >Hence for kdump kernel, people never want to do a cpu hot plug in there.
> >That's why we want to use nr_cpus to limit the number of possible cpu to
> >save memory. E.g still on my laptop, if I want to do a kdump, the number
> >of possible cpu is still 8, but you may want to use only 1 cpu to dump,
> >maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
> >nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
> >memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
> >is much better. While with specifying max_cpus=1, the number of possible
> >cpu is still 8. That's the reason. On x86_64 and s390, there's another
> >kernel para "possible_cpus=xx" which can be used to set possible cpus for
> >cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
> >I am not very sure why this is introduced, number of possible cpu is
> >decided by the min value of nr_cpus= and possible_cpus=.
> >
> >nr_cpus and maxcpus might not be very clear to people which are
> >described in Documentation/kernel-parameters.txt.
> >
> >Hi Jon, do you think change as below is OK to you?
> >
> >
> > From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
> >From: Baoquan He <bhe@redhat.com>
> >Date: Wed, 24 Aug 2016 11:14:34 +0800
> >Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
> >  and maxcpus
> >
> > From the old description people still can't get what's the exact
> >difference between nr_cpus and maxcpus. Especially in kdump kernel
> >nr_cpus is always suggested if it's implemented in the ARCH. The
> >reason is nr_cpus is used to limit the max number of possible cpu
> >in system, the sum of already plugged cpus and hot plug cpus can't
> >exceed its value. However maxcpus is used to limit how many cpus
> >are allowed to be brought up during bootup.
> >
> >Signed-off-by: Baoquan He <bhe@redhat.com>
> >---
> >  Documentation/kernel-parameters.txt | 20 +++++++++++++-------
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> >
> >diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> >index 46c030a..25d3b36 100644
> >--- a/Documentation/kernel-parameters.txt
> >+++ b/Documentation/kernel-parameters.txt
> >@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> >  			than or equal to this physical address is ignored.
> >
> >  	maxcpus=	[SMP] Maximum number of processors that	an SMP kernel
> >-			should make use of.  maxcpus=n : n >= 0 limits the
> >-			kernel to using 'n' processors.  n=0 is a special case,
> >-			it is equivalent to "nosmp", which also disables
> >-			the IO APIC.
> >+			will bring up during bootup.  maxcpus=n : n >= 0 limits
> >+			the kernel to bring up 'n' processors. Surely after
> >+			bootup you can bring up the other plugged cpu by executing
> >+			"echo 1 > /sys/devices/system/cpu/cpuX/online". So maxcpus
> >+			only takes effect during system bootup.
> >+			While n=0 is a special case, it is equivalent to "nosmp",
> >+			which also disables the IO APIC.
> >
> >  	max_loop=	[LOOP] The number of loop block devices that get
> >  	(loop.max_loop)	unconditionally pre-created at init time. The default
> >@@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> >
> >  	nr_cpus=	[SMP] Maximum number of processors that	an SMP kernel
> >  			could support.  nr_cpus=n : n >= 1 limits the kernel to
> >-			supporting 'n' processors. Later in runtime you can not
> >-			use hotplug cpu feature to put more cpu back to online.
> >-			just like you compile the kernel NR_CPUS=n
> >+			support 'n' processors. It could be larger than the
> >+			number of already plugged CPU during bootup, later in
> >+			runtime you can physically add extra cpu until it reaches
> >+			n. So during boot up some boot time memory for per-cpu
> >+			variables need be pre-allocated for later physical cpu
> >+			hot plugging.
> >
> >  	nr_uarts=	[SERIAL] maximum number of UARTs to be registered.
> >
> >
> 
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec