[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 at 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 at 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 at 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.
> >
> >
> 
>