From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BD8DC433F5 for ; Tue, 1 Mar 2022 14:32:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E15F18D0002; Tue, 1 Mar 2022 09:31:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DC36F8D0001; Tue, 1 Mar 2022 09:31:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB2BB8D0002; Tue, 1 Mar 2022 09:31:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id BD7C68D0001 for ; Tue, 1 Mar 2022 09:31:59 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 768129AC8F for ; Tue, 1 Mar 2022 14:31:59 +0000 (UTC) X-FDA: 79196056758.25.999E806 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id CFD582000D for ; Tue, 1 Mar 2022 14:31:58 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BFD41615A9; Tue, 1 Mar 2022 14:31:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AE37C340EE; Tue, 1 Mar 2022 14:31:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646145115; bh=iJGcKs3EFTZxwY5OYzsHuFQIOWVuyWXpcuW8J5KMOfI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XzEYZqdNO26snXjLDdHwtozmVQkSkeCS42yZ9Pk0EsfUBJI35V0icrfHKmRhDfEzt jABS9bDzz0ZNov4uq6Fp2s++Zyb4dW1GAa6FJthe0lk0pqMFXv+3KGRH+cSUJ1cxR5 wYvcH9/9l+ciwXo2fjQwDTgLOaTdDtSXA+kA/dSgsNmsAO0BGasD7SyMWtMRrOTe/U QXiwtBs7BPdK95H3+C2hRD1OM5G/6FaYw4qaqiCkx1hVl+NIY3UHhX+LS2ndjFEqHn YlIk4DtjPzM5LJ/TLVK+SRoWGzo6pykfaO4pyTdEexL3ZwN1wYnt9mBmHHq5+WT/Vv p+hmtIJAarKOg== Date: Tue, 1 Mar 2022 16:31:46 +0200 From: Mike Rapoport To: Tiezhu Yang Cc: Thomas Bogendoerfer , Andrew Morton , Xuefeng Li , linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Message-ID: References: <1646108941-27919-1-git-send-email-yangtiezhu@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: 8368bjz9ezxqej1gnf5zws5yqn499imr Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XzEYZqdN; spf=pass (imf13.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Queue-Id: CFD582000D X-HE-Tag: 1646145118-823853 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote: > > > On 03/01/2022 05:55 PM, Mike Rapoport wrote: > > Hi, > > > > On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote: > > > In the current code, the kernel command-line parameter mem= and memmap= > > > can not work well on MIPS, this patchset refactors the related code to > > > fix them. > > > > > > For kdump on MIPS, if the users want to limit the memory region for the > > > capture kernel to avoid corrupting the memory image of the panic kernel, > > > use the parameter memmap=limit@base is the proper way, I will submit a > > > patch to use memmap=limit@base for kexec-tools after this patchset is > > > applied. > > > > Sorry, apparently I misread the prevoius version. > > What's wrong with the current implementation of mem=limit@base for the > > kdump case? > > In the current code, without this patchset, kernel boot hangs when add > mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that > the parameter mem= and memmap= have bug on mips. I can see how mem=3G may be wrong when the memory does not start at 0, but it seems to do the right thing of mem=3G@64M. Do you see system hangs with mem=3G@64M? Do you have the logs before the hang? As for memmap= option, it does not specify the memory map but rather alters the memory map passed by the firmware. Particularity in MIPS implementation it allows to add a single range of available or reserved memory. AFAIU, for the kdump use-case mem=X@Y should suffice. > Thanks, > Tiezhu > > > > > > v4: Fix some build warnings reported by kernel test robot > > > > > > v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base, > > > commented by Mike Rapoport, thank you > > > > > > v2: Add some new patches to support memmap=limit@base > > > > > > Tiezhu Yang (4): > > > MIPS: Refactor early_parse_mem() to fix mem= parameter > > > memblock: Introduce memblock_mem_range_remove_map() > > > MIPS: Refactor early_parse_memmap() to fix memmap= parameter > > > MIPS: Remove not used variable usermem > > > > > > arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++-------------------------- > > > include/linux/memblock.h | 1 + > > > mm/memblock.c | 9 +++++-- > > > 3 files changed, 40 insertions(+), 39 deletions(-) > > > > > > -- > > > 2.1.0 > > > > > > -- Sincerely yours, Mike.