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 29D90C4332F for ; Fri, 4 Mar 2022 17:05:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 911948D0002; Fri, 4 Mar 2022 12:05:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C0688D0001; Fri, 4 Mar 2022 12:05:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7AF418D0002; Fri, 4 Mar 2022 12:05:50 -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 6989D8D0001 for ; Fri, 4 Mar 2022 12:05:50 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 26F7C223DF for ; Fri, 4 Mar 2022 17:05:50 +0000 (UTC) X-FDA: 79207330860.03.0F1A8E9 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by imf26.hostedemail.com (Postfix) with ESMTP id CDA7A14003C for ; Fri, 4 Mar 2022 17:05:48 +0000 (UTC) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 39EED92009C; Fri, 4 Mar 2022 18:05:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 3295992009B; Fri, 4 Mar 2022 17:05:46 +0000 (GMT) Date: Fri, 4 Mar 2022 17:05:46 +0000 (GMT) From: "Maciej W. Rozycki" To: Tiezhu Yang cc: Mike Rapoport , 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 In-Reply-To: <8956c625-c18d-846e-3e65-7920776b27f3@loongson.cn> Message-ID: References: <1646108941-27919-1-git-send-email-yangtiezhu@loongson.cn> <8956c625-c18d-846e-3e65-7920776b27f3@loongson.cn> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: CDA7A14003C X-Stat-Signature: b9j977zrpc7rj99hncyost6tztmg47hs Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=none; spf=none (imf26.hostedemail.com: domain of macro@orcam.me.uk has no SPF policy when checking 78.133.224.34) smtp.mailfrom=macro@orcam.me.uk X-HE-Tag: 1646413548-757428 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 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