Message-ID: <57BF9142.6060600@cn.fujitsu.com>
Date:   Fri, 26 Aug 2016 08:45:54 +0800
From:   "Zhou, Wenjian/周文剑" 
        <zhouwj-fnst@...fujitsu.com>
To:     Baoquan He <bhe@...hat.com>, Jonathan Corbet <corbet@....net>
CC:     <linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
        <dyoung@...hat.com>, <vgoyal@...hat.com>,
        <kexec@...ts.infradead.org>, <linux-doc@...r.kernel.org>,
        <xlpang@...hat.com>, <joe@...ches.com>
Subject: Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

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@...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@...hat.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@...hat.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.
>
>

Powered by blists - more mailing lists