Re: [PATCH] mm/hotplug: Only respect mem= parameter during boot stage

[Baoquan He <bhe@redhat.com>]

On 12/10/19 at 03:19pm, Michal Hocko wrote:
> On Tue 10-12-19 22:05:34, Baoquan He wrote:
> > On 12/10/19 at 02:32pm, Michal Hocko wrote:
> > > On Tue 10-12-19 20:55:57, Baoquan He wrote:
> > > [...]
> > > > Btw, as you said at above, I am confused by the '[KNL,BOOT]', what does
> > > > the 'BOOT' mean in the documentation of 'mem='? I checked all parameters
> > > > with 'BOOT', still don't get it clearly.
> > > 
> > > This is a good question indeed. I have checked closer and this is what
> > > documentation says
> > > Documentation/admin-guide/kernel-parameters.rst
> > > "
> > >         BOOT    Is a boot loader parameter.
> > > 
> > > Parameters denoted with BOOT are actually interpreted by the boot
> > > loader, and have no meaning to the kernel directly.
> > > "
> > > 
> > > and that really doesn't fit, right? So I went to check the full history
> > > git tree just to get to 2.4.0-test5 and no explanation whatsoever.
> > > Fun, isn't it? ;)
> > 
> > Yeah, very interesting. Finally I got their original purpose from
> > Documentation/x86/boot.rst.
> > 
> > 
> > Special Command Line Options
> > ============================
> > 
> > If the command line provided by the boot loader is entered by the
> > user, the user may expect the following command line options to work.
> > They should normally not be deleted from the kernel command line even
> > though not all of them are actually meaningful to the kernel.  Boot
> > loader authors who need additional command line options for the boot
> > loader itself should get them registered in
> > Documentation/admin-guide/kernel-parameters.rst to make sure they will not
> > conflict with actual kernel options now or in the future.
> > 
> > ...
> > 
> > So here, [KNL,BOOT], KNL means it's used for kernel, BOOT means it's
> > needed by boot loader.
> 
> OK, that clarifies this a bit. Thanks for referencing to it!
> That should explain how the behavior is not boot time restricted at all
> and the current implementation is actually correct. So a change to it
> should clearly state the new usecase as we have already discussed. In
> case there are bootloaders which really rely on the original strict
> meaning then we should be able to compare cost/benfits of those two
> usecases.

Sounds reasonable to me. From the current parameters for x86, it only
impact the bootloader during boot-time, e.g 'mem= ' says bootloader need
this to place initrd. It might not give the trouble, anyway, we will
say.

Just a little more, we have test case for memory hotplug which only test
the DIMM added after boot. And the old 'mem= ' implementation in x86
only erazes memory regions above 'mem= ' in e820 table. That is why the
behaviour change immediately gave me a surprise when I noticed people
back ported Jurgen's patch to our distros. 

So glad to see all is clear, thanks.