Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter

[Mike Rapoport]

On Sat, Mar 05, 2022 at 02:19:41PM +0800, Tiezhu Yang wrote:
> 
> 
> 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@xxxxxxxxxxxxxxxxxxxx/>
> > 
> > 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.

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.
 
> 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
> 

-- 
Sincerely yours,
Mike.