On 3/9/22 3:24 PM, Mike Rapoport wrote: > From: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > The existing description of mem= does not cover all the cases and > differences between how architectures treat it. > > Extend the description to match the code. > > Signed-off-by: Mike Rapoport <rppt@xxxxxxxxxxxxx> > --- > > This is in a way a followup for the discussion of mem= usage on MIPS: > > https://lore.kernel.org/all/1646461289-31992-1-git-send-email-yangtiezhu@xxxxxxxxxxx > > .../admin-guide/kernel-parameters.txt | 20 +++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index f5a27f067db9..f3597841a031 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -2834,6 +2834,15 @@ > 2 when the kernel is not able to see the whole system memory; > 3 memory that lies after 'mem=' boundary is excluded from > the hypervisor, then assigned to KVM guests. > + 4 to limit the memory available for kdump kernel. > + > + [ARC,MICROBLAZE] - the limit applies only to low memory, > + high memory is not affected. > + > + [ARM64] - only limits memory covered by the linear > + mapping. The NOMAP regions are not affected. > + > + [HEXAGON] - must be use Used? > to set the memory size, there is What? :-) [...] MBR, Sergey