From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754746AbcH0Aif (ORCPT ); Fri, 26 Aug 2016 20:38:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40884 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754681AbcH0Aid (ORCPT ); Fri, 26 Aug 2016 20:38:33 -0400 Date: Sat, 27 Aug 2016 08:38:29 +0800 From: Baoquan He To: =?utf-8?B?Ilpob3UsIFdlbmppYW4v5ZGo5paH5YmRIg==?= Cc: Jonathan Corbet , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, dyoung@redhat.com, vgoyal@redhat.com, kexec@lists.infradead.org, linux-doc@vger.kernel.org, xlpang@redhat.com, joe@perches.com Subject: Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus Message-ID: <20160827003829.GE31627@x1.redhat.com> 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> <57BF9142.6060600@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <57BF9142.6060600@cn.fujitsu.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Sat, 27 Aug 2016 00:38:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/周文剑" 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. > > > > > >