linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tiezhu Yang <yangtiezhu@loongson.cn>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Mike Rapoport <rppt@kernel.org>,
	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 14:19:41 +0800	[thread overview]
Message-ID: <4e10d7a4-3b3e-a220-8cd2-565614288950@loongson.cn> (raw)
In-Reply-To: <alpine.DEB.2.21.2203041627150.47558@angie.orcam.me.uk>



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:
>
> <https://lore.kernel.org/linux-mips/alpine.LFD.2.21.2010050133330.333514@eddie.linux-mips.org/>
>
> 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.

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


  reply	other threads:[~2022-03-05  6:20 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 [this message]
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=4e10d7a4-3b3e-a220-8cd2-565614288950@loongson.cn \
    --to=yangtiezhu@loongson.cn \
    --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=rppt@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).