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 3B242C433EF for ; Sat, 5 Mar 2022 20:09:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6623C6B0071; Sat, 5 Mar 2022 15:09:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 610966B0072; Sat, 5 Mar 2022 15:09:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FFA96B0073; Sat, 5 Mar 2022 15:09:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 3CCF06B0071 for ; Sat, 5 Mar 2022 15:09:47 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 0CA04601C0 for ; Sat, 5 Mar 2022 20:09:47 +0000 (UTC) X-FDA: 79211423214.10.B83752C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 3664A20002 for ; Sat, 5 Mar 2022 20:09:46 +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 426D860B76; Sat, 5 Mar 2022 20:09:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2014C004E1; Sat, 5 Mar 2022 20:09:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646510984; bh=Z797Y7dPt9dgaRbnjf5KloG1BlL0Aq4hMvRukaJ3WzI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SB4IoPKCSfquWYvbGqOw7m2BfjhC/gtGoYuzF6LlvjV13gi2qqsTlvFDHkusMnRqg Hp6AmtuK8EhZ/p4LcX7t5ArqcPyfubPVtrMDYZLF9mO4OzTfMnUPGaikkJFYb6Zrwa Z9TwLMZ38drrWErJA9eWhtDUONUDyf72iROl+pq5CyP+qmNIAQU2Kff51cIa3l1tkI 8tNUAPptys7h0rJzvK+JqEayWxRgK2paebrvHqXuRXF55onMAST5n9Ez4gfMd96poV MHZcOZnFV7ZQnjdcihtdjCJ7sV+Z565h1j4bIRi4JOksacLDyz0rBm/5mKFko6Cng4 LOQBCMV6mzM3A== Date: Sat, 5 Mar 2022 22:09:34 +0200 From: Mike Rapoport To: "Maciej W. Rozycki" Cc: Tiezhu Yang , 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: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 3664A20002 X-Stat-Signature: sm7puwxeb8si7sfz99ddeibqzd1s55uo Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SB4IoPKC; 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-Rspam-User: X-HE-Tag: 1646510986-15883 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 07:21:15PM +0000, Maciej W. Rozycki wrote: > On Sat, 5 Mar 2022, Mike Rapoport wrote: > > > > > 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. > > There's nothing to implement as the MIPS port has supported arbitrary > memory maps since Dec 11th, 2000; that's almost 22 years now. C.f.: > , > . You are right, and providing mem=X@Y for each contiguous memory range should work even after 22 years. I missed the fact that mem= can be repeated several times. > Sadly commit a09fc446fb6d ("[MIPS] setup.c: use early_param() for early > command line parsing") removed last pieces of inline documentation; I > don't know why things like that get approved, but neither I can take > responsibility. This is sad indeed, but we still can update the kernel-parameters.txt with a MIPS paragraph. > Maciej -- Sincerely yours, Mike.