From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964940AbcHBOXm (ORCPT ); Tue, 2 Aug 2016 10:23:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41660 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964886AbcHBOVv (ORCPT ); Tue, 2 Aug 2016 10:21:51 -0400 Date: Tue, 2 Aug 2016 22:09:55 +0800 From: Baoquan He To: =?utf-8?B?Ilpob3UsIFdlbmppYW4v5ZGo5paH5YmRIg==?= Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org, dyoung@redhat.com, d.hatayama@jp.fujitsu.com Subject: Re: [PATCH v2] Documentation: kdump: add description of bringing up SMP dump-capture kernel Message-ID: <20160802140955.GB3663@x1.redhat.com> References: <1470010988-18050-1-git-send-email-zhouwj-fnst@cn.fujitsu.com> <20160802074602.GA3663@x1.redhat.com> <57A05E7D.90101@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <57A05E7D.90101@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.31]); Tue, 02 Aug 2016 14:09:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/02/16 at 04:49pm, "Zhou, Wenjian/周文剑" wrote: > Hi Baoquan, > > On 08/02/2016 03:46 PM, Baoquan He wrote: > >Hi Wenjian, > > > >On 08/01/16 at 08:23am, Zhou Wenjian wrote: > >>v1->v2: change nr_cpus to maxcpus > >> > >>SMP dump-capture kernel is useful to improve the performance of kdump in > >>some cases. So add the description of bringing up SMP dump-capture kernel. > >> > >>Signed-off-by: Zhou Wenjian > > > >Discussed with people, it could be better to adjust the > >description about nr_cpus and maxcpus part. I think you can still > >describe nr_cpus/maxcpus in patch 1/2, and keep parallel dumping part in > >2/2. > > > >Originally maxcpus=1 is used for all ARCHes. Later people found > >nr_cpus=1 is better since nr_cpus decides the number of possible cpu > >while maxcpus decides the max working cpu after system boot. So nr_cpus > >can save memory because percpu will pre-allocate memory for each > >possible cpu for hotplug. So on x86 nr_cpus is used because much memory > >can be saved if possible cpu number is very large. > > > >So you can mention that both maxcpus and nr_cpus can be used but nr_cpus > >has advantage if it has been implemented in some ARCHes like x86_64. And > >I guess you mush have tested parallel dumping feature with nr_cpus > >specified, it makes sense to tell people with the real situation. > > > > I think it is better to describe the difference in somewhere else. > Maybe, it's a good choice which just replace maxcpus by maxcpus/nr_cpus. > Then user can choose maxcpus or nr_cpus. > What do you think about it? Putting it in kdump.txt could be better. nr_cpus/maxcpus are normal kernel options, the reason we mentioned them here is crashkernel memory is usually limited, we have to try our best to save memory. So if nr_cpus is available on some ARCHes, we should use it. On x86 nr_cpus=1 has been taken for kdump kernel for a very long time. I think letting people know below things would be good: ~~~~~~~~~~ Firslty both maxcpus and nr_cpus can be used for kdump kernel to specify number of allowed cpu. maxcpus only specify the number of available cpu, while nr_cpus will specify the number of possible cpu which is necessary for hotplug. nr_cpus can be used to limit the amount of percpu memory pre-allocation. And now you just test parallel dumping feature on x86, or more specifically on x86_64. ~~~~~~~~~~~ Thanks Baoquan