From: Mike Rapoport <rppt@kernel.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Andrew Morton <akpm@linux-foundation.org>,
Xuefeng Li <lixuefeng@loongson.cn>,
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
Date: Sat, 5 Mar 2022 22:09:34 +0200 [thread overview]
Message-ID: <YiPDfhfwYUQy9Pfd@kernel.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2203051837280.47558@angie.orcam.me.uk>
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.:
> <https://lore.kernel.org/linux-mips/Pine.GSO.3.96.1000814133957.7256S-100000@delta.ds2.pg.gda.pl/>,
> <https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=97b7ae4257ef>.
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.
next prev parent reply other threads:[~2022-03-05 20:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 4:28 [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Tiezhu Yang
2022-03-01 4:28 ` [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter Tiezhu Yang
2022-03-04 15:10 ` Thomas Bogendoerfer
2022-03-04 15:35 ` Thomas Bogendoerfer
2022-03-04 17:11 ` Maciej W. Rozycki
2022-03-05 13:13 ` Mike Rapoport
2022-03-07 16:29 ` Thomas Bogendoerfer
2022-03-07 22:07 ` Mike Rapoport
2022-03-07 23:09 ` Maciej W. Rozycki
2022-03-01 4:28 ` [PATCH v4 2/4] memblock: Introduce memblock_mem_range_remove_map() Tiezhu Yang
2022-03-01 4:29 ` [PATCH v4 3/4] MIPS: Refactor early_parse_memmap() to fix memmap= parameter Tiezhu Yang
2022-03-01 4:29 ` [PATCH v4 4/4] MIPS: Remove not used variable usermem Tiezhu Yang
2022-03-01 9:55 ` [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Mike Rapoport
2022-03-01 11:51 ` Tiezhu Yang
2022-03-01 14:31 ` Mike Rapoport
2022-03-02 1:50 ` Tiezhu Yang
2022-03-02 8:03 ` Mike Rapoport
2022-03-02 9:28 ` Tiezhu Yang
2022-03-02 12:50 ` Mike Rapoport
2022-03-04 17:05 ` Maciej W. Rozycki
2022-03-05 6:19 ` Tiezhu Yang
2022-03-05 13:26 ` Mike Rapoport
2022-03-05 19:21 ` Maciej W. Rozycki
2022-03-05 20:09 ` Mike Rapoport [this message]
2022-03-06 1:22 ` Maciej W. Rozycki
2022-03-05 20:53 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YiPDfhfwYUQy9Pfd@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lixuefeng@loongson.cn \
--cc=macro@orcam.me.uk \
--cc=tsbogend@alpha.franken.de \
--cc=yangtiezhu@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.