From: Baoquan He <bhe@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
jgross@suse.com, william.kucharski@oracle.com, mingo@kernel.org,
akpm@linux-foundation.org
Subject: Re: [PATCH] mm/hotplug: Only respect mem= parameter during boot stage
Date: Tue, 10 Dec 2019 20:55:57 +0800 [thread overview]
Message-ID: <20191210125557.GA28917@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20191210113341.GG10404@dhcp22.suse.cz>
On 12/10/19 at 12:33pm, Michal Hocko wrote:
> On Tue 10-12-19 18:43:03, Baoquan He wrote:
> > On 12/10/19 at 11:28am, Michal Hocko wrote:
> > > On Tue 10-12-19 15:24:53, Baoquan He wrote:
> [...]
> > > > But after system bootup, we should be able to hot add/remove any memory
> > > > board. This should not be restricted by a boot-time kernel parameter
> > > > 'mme='. This is what I am trying to fix.
> > >
> > > This is a simple statement without any actual explanation on why. Why is
> > > hotplug memory special? What is the usecase? Who would want to use mem
> > > parameter and later expect a memory above the restrected area to be
> > > hotplugable?
> >
> > The why is 'mem=' is used to restrict the amount of system ram during
> > boot. We have two ways to add system memory, one is installing DIMMs
> > before boot, the other is hot adding memory after boot. Without David's
> > use case, we may need redefine 'mem=' and change its documentation in
> > kernel-parameters.txt, if we don't want to fix it like this. Otherwise,
> > 'mem=' will limit the system's upper system ram always, that is not
> > expected.
>
> I really do not see why. It seems a pretty consistent behavior to me.
> Because it essentially cut any memory above the given size. If a new
> hotplugable memory fits into that cap then it just shows up. Quite
> contrary I would consider it unexpected that a memory higher than the
> given mem=XYZ is really there. But I do recognize a real usecase
> mentioned elsewhere which beats the consistency argument here because
> all setups where such a restriction would be really important are
> debugging/workaround AFAICS.
All right. There could be me who have this misunderstanding.
Anyway, I think now we all agree it's only a boot-time restriction on
the system RAM.
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.
Thanks
Baoquan
next prev parent reply other threads:[~2019-12-10 12:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-06 15:05 [PATCH] mm/hotplug: Only respect mem= parameter during boot stage Baoquan He
2019-12-09 9:43 ` David Hildenbrand
2019-12-09 10:07 ` Michal Hocko
2019-12-09 10:24 ` Jürgen Groß
2019-12-09 11:01 ` David Hildenbrand
2019-12-09 11:08 ` Jürgen Groß
2019-12-09 11:11 ` David Hildenbrand
2019-12-10 8:04 ` Baoquan He
2019-12-10 7:24 ` Baoquan He
2019-12-10 10:28 ` Michal Hocko
2019-12-10 10:43 ` Baoquan He
2019-12-10 11:33 ` Michal Hocko
2019-12-10 12:55 ` Baoquan He [this message]
2019-12-10 13:32 ` Michal Hocko
2019-12-10 14:05 ` Baoquan He
2019-12-10 14:19 ` Michal Hocko
2019-12-11 13:20 ` Baoquan He
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=20191210125557.GA28917@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mingo@kernel.org \
--cc=william.kucharski@oracle.com \
/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.