From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753698AbcHSAsm (ORCPT ); Thu, 18 Aug 2016 20:48:42 -0400 Received: from tex.lwn.net ([70.33.254.29]:34656 "EHLO vena.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753514AbcHSAsj (ORCPT ); Thu, 18 Aug 2016 20:48:39 -0400 Date: Thu, 18 Aug 2016 11:18:54 -0600 From: Jonathan Corbet To: Zhou Wenjian Cc: , , , , , , , , Subject: Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus Message-ID: <20160818111854.362bb972@lwn.net> In-Reply-To: <1471489907-27737-2-git-send-email-zhouwj-fnst@cn.fujitsu.com> References: <1471489907-27737-1-git-send-email-zhouwj-fnst@cn.fujitsu.com> <1471489907-27737-2-git-send-email-zhouwj-fnst@cn.fujitsu.com> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Aug 2016 11:11:46 +0800 Zhou Wenjian wrote: Thank you for working to improve the documentation! > * We generally don' have to bring up a SMP kernel just to capture the > dump. Hence generally it is useful either to build a UP dump-capture > kernel or specify maxcpus=1 option while loading dump-capture kernel. > + Note, though maxcpus always works, you should replace it by nr_cpus to > + save memory if supported by the current ARCH, such as x86. So, IMHO, this seems like the wrong place for this. I've just spent a bit of time staring at kernel-parameters.txt, and there is no way for a clueless user like me to know what the difference is between maxcpus= and nr_cpus= would be. A far better patch would be to update the documentation there to make that clear. Any chance you would be willing to do that? Then, rather than tacking an "ignore what you just read" note into kdump.txt, it could maybe be rewritten to simply say what users should do? Thanks, jon From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from tex.lwn.net ([70.33.254.29] helo=vena.lwn.net) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1baQyM-0001RM-VS for kexec@lists.infradead.org; Thu, 18 Aug 2016 17:19:19 +0000 Date: Thu, 18 Aug 2016 11:18:54 -0600 From: Jonathan Corbet Subject: Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus Message-ID: <20160818111854.362bb972@lwn.net> In-Reply-To: <1471489907-27737-2-git-send-email-zhouwj-fnst@cn.fujitsu.com> References: <1471489907-27737-1-git-send-email-zhouwj-fnst@cn.fujitsu.com> <1471489907-27737-2-git-send-email-zhouwj-fnst@cn.fujitsu.com> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Zhou Wenjian Cc: bhe@redhat.com, linux-doc@vger.kernel.org, xlpang@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, joe@perches.com, akpm@linux-foundation.org, dyoung@redhat.com, vgoyal@redhat.com On Thu, 18 Aug 2016 11:11:46 +0800 Zhou Wenjian wrote: Thank you for working to improve the documentation! > * We generally don' have to bring up a SMP kernel just to capture the > dump. Hence generally it is useful either to build a UP dump-capture > kernel or specify maxcpus=1 option while loading dump-capture kernel. > + Note, though maxcpus always works, you should replace it by nr_cpus to > + save memory if supported by the current ARCH, such as x86. So, IMHO, this seems like the wrong place for this. I've just spent a bit of time staring at kernel-parameters.txt, and there is no way for a clueless user like me to know what the difference is between maxcpus= and nr_cpus= would be. A far better patch would be to update the documentation there to make that clear. Any chance you would be willing to do that? Then, rather than tacking an "ignore what you just read" note into kdump.txt, it could maybe be rewritten to simply say what users should do? Thanks, jon _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec