From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753877AbcHZAtj (ORCPT ); Thu, 25 Aug 2016 20:49:39 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:27992 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751795AbcHZAti (ORCPT ); Thu, 25 Aug 2016 20:49:38 -0400 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="10302752" Message-ID: <57BF9142.6060600@cn.fujitsu.com> Date: Fri, 26 Aug 2016 08:45:54 +0800 From: =?UTF-8?B?Ilpob3UsIFdlbmppYW4v5ZGo5paH5YmRIg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Baoquan He , Jonathan Corbet CC: , , , , , , , Subject: Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus References: <1471489907-27737-1-git-send-email-zhouwj-fnst@cn.fujitsu.com> <1471489907-27737-2-git-send-email-zhouwj-fnst@cn.fujitsu.com> <20160818111854.362bb972@lwn.net> <57B653D1.8060106@cn.fujitsu.com> <20160819095740.1cccc073@lwn.net> <57BA51E0.1070902@cn.fujitsu.com> <20160824050645.GA8279@x1.redhat.com> In-Reply-To: <20160824050645.GA8279@x1.redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-yoursite-MailScanner-ID: C782F41C0B94.AC613 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: zhouwj-fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/周文剑" 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 > 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 > --- > 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. > >