From: Mike Rapoport <rppt@kernel.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
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 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter
Date: Sat, 5 Mar 2022 15:13:54 +0200 [thread overview]
Message-ID: <YiNiEqC294xQ6PXD@kernel.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2203041634040.47558@angie.orcam.me.uk>
On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote:
> On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote:
>
> > > > With this patch, when add "mem=3G" to the command-line, the
> > > > kernel boots successfully, we can see the following messages:
> > >
> > > unfortunately this patch would break platforms without memory detection,
> > > which simply use mem=32M for memory configuration. Not sure how many
> > > rely on this mechanism. If we can make sure nobody uses it, I'm fine
> > > with your patch.
> >
> > maybe we could add a CONFIG option, which will be selected by
> > platforms, which don't need/want this usermem thing.
>
> FWIW I don't understand what the issue is here beyond that we have a bug
> that causes a system to hang when "mem=3G" is passed on the kernel command
> line. That is assuming that system does have contiguous RAM available for
> the kernel to use from address 0 up to 3GiB; otherwise it's a user error
> to tell the kernel it has that memory available (I did get bitten by that
> myself too): garbage in, garbage out.
This is exactly the case here because the system does not have contiguous
RAM:
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000004000000-0x000000000effffff]
[ 0.000000] node 0: [mem 0x0000000090200000-0x00000000ffffffff]
[ 0.000000] node 0: [mem 0x0000000120000000-0x00000001653fffff]
(from patch 3/4 in this series)
I don't see what "bug" this patch is trying to fix. Is indeed possible to
make MIPS' mem= behave like it does not arm64 and ppc, but that would break
systems that use current semantics and I recall seeing some of OpenWRT
machines using mem= to override memory map supplied by firmware.
> Maciej
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2022-03-05 13:14 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 [this message]
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
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=YiNiEqC294xQ6PXD@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.