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 9F0EFC433EF for ; Sat, 5 Mar 2022 13:26:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB8DF6B009D; Sat, 5 Mar 2022 08:26:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E41AE6B009E; Sat, 5 Mar 2022 08:26:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D081B6B009F; Sat, 5 Mar 2022 08:26:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id BE9076B009D for ; Sat, 5 Mar 2022 08:26:52 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8CC9A23B6D for ; Sat, 5 Mar 2022 13:26:52 +0000 (UTC) X-FDA: 79210407864.05.9A326F6 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id F1ECB40002 for ; Sat, 5 Mar 2022 13:26:51 +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 ams.source.kernel.org (Postfix) with ESMTPS id 44BC3B80BE8; Sat, 5 Mar 2022 13:26:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E94DC004E1; Sat, 5 Mar 2022 13:26:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646486808; bh=fM8MLz1GwvBs2cvfUtWJCjMtw5Xf1RDOc8eABrLldLc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r4IYZ9h20AWr9yqWCMW/MA7rOCR2E5+tj1WrBdqGAUpjCKiykuVA1OQpCkCHR5J2f MKATFpDtLOoM3G36Un89G8gbZ2vVug9La+F9UULFwIU9a3Qxq9NJtdo9Ta864Y8v18 mMnUDLT2m0vWdV53UAX9mu2Wv1hx+IyYy14YWSC+bWQTXqlt1ejbwLE4qqiy1cPRF5 VDvvVwzJnl8/nBQlJQEHdt0ZuAto2dl8gtvZtVT/USUxpmMm7pcJm1XhIBj/k+Zy8O 8n86T1QsdDbugDeLczeIP/zDQudB7ZYHqU4sW6soOCz/MiMaLRpIXvK3sdcfByH9TK zLHqNt2QLcFtQ== Date: Sat, 5 Mar 2022 15:26:39 +0200 From: Mike Rapoport To: Tiezhu Yang Cc: "Maciej W. Rozycki" , 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> <8956c625-c18d-846e-3e65-7920776b27f3@loongson.cn> <4e10d7a4-3b3e-a220-8cd2-565614288950@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e10d7a4-3b3e-a220-8cd2-565614288950@loongson.cn> X-Rspamd-Queue-Id: F1ECB40002 X-Stat-Signature: s7oytaj6tt8bqab6tej3m5usgpgqguwn X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r4IYZ9h2; spf=pass (imf04.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam07 X-HE-Tag: 1646486811-436766 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 Sat, Mar 05, 2022 at 02:19:41PM +0800, Tiezhu Yang wrote: > > > On 03/05/2022 01:05 AM, Maciej W. Rozycki wrote: > > On Wed, 2 Mar 2022, Tiezhu Yang wrote: > > > > > > 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. > > > > > > We can modify some code to make mem=X@Y work well, > > > but according to Documentation/admin-guide/kernel-parameters.txt, > > > the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems > > > odd, the intention of this patchset is to make mem= and memmap= > > > work well and consistent with the other archs. > > > > It is not the MIPS implementation that is odd, it is the others that have > > changed the semantics that are. > > > > When I added `mem=...' support to the MIPS platform, back on Dec 11th, > > 2000, which I needed for a system with with memory holes until I got > > proper memory probing implemented, AFAIR the only other implementation was > > for the x86 and naturally what I did for the MIPS platform was exactly the > > same. It used to be documented too, but the documentation was removed > > sometime back in 2003 when someone has changed the x86 semantics for > > reasons unknown to me and without letting people working on other > > platforms know, so things diverged. > > > > Please review: > > > > > > > > as it has been already discussed. > > > > If you have a system that hangs with `mem=3G' and which does have > > contiguous RAM available for the kernel to use from 0 through to 3GiB, > > then please either bisect the problem or try finding the root cause as it > > used to work at least those 21 years ago. Conversely if your system does > > *not* have such RAM available, then use the correct option(s) instead that > > reflect your memory map. > > > > It is preferable that the memory map be determined automatically either > > by the firmware and then passed to the kernel somehow, or a device tree > > entry, or probed by the kernel itself. You shouldn't have to specify > > `mem=...' by hand except for debugging or as a temporary workaround. > > > > For example I have an x86 system that Linux does not how to interrogate > > for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the > > x86 platform has a special exception to always exclude area between 640K > > and 1M from being used even if not explicitly specified, but we do not > > have a need for such legacy such legacy concerns with the MIPS port). I > > consider it an interim measure however until the kernel has been fixed. > > > > Maciej > > > > Hi Mike, Thomas and Maciej, > > Thank you very much for your feedbacks and discussions. > > To be frank, I think mem= and memmap= are used for debugging and testing > in most cases, the intention of this patchset is to refactor the related > code to make them work well on mips. mem= works fine on mips and there is no need to change it. If you must supply complex memory layout on the command line, consider implementing support for memmap=exact and multiple memmap= parameters on the kernel command line, like x86 does. > Now, if put the current patch #2 as the first patch, and then modify the > current patch #1 to support both mem=limit and mem=limit@base (if @base > is omitted, it is equivalent to mem=limit), the other patches #3 and #4 > remain unchanged, make sense? > > I will send v5 for your review. > > Thanks, > Tiezhu > -- Sincerely yours, Mike.