All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: "Jürgen Groß" <jgross@suse.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, mhocko@kernel.org, david@redhat.com,
	bsingharora@gmail.com
Subject: Re: [PATCH v3] mm/hotplug: Only respect mem= parameter during boot stage
Date: Thu, 6 Feb 2020 10:58:43 +0800	[thread overview]
Message-ID: <20200206025843.GL8965@MiWiFi-R3L-srv> (raw)
In-Reply-To: <1356631d-30b6-e967-9874-6c48c25304cf@suse.com>

On 02/04/20 at 08:53am, Jürgen Groß wrote:
> On 04.02.20 06:06, Baoquan He wrote:
> > In commit 357b4da50a62 ("x86: respect memory size limiting via mem=
> > parameter") a global varialbe max_mem_size is added to store
> > the value parsed from 'mem= ', then checked when memory region is
> > added. This truly stops those DIMMs from being added into system memory
> > during boot-time.
> > 
> > However, it also limits the later memory hotplug functionality. Any
> > DIMM can't be hotplugged any more if its region is beyond the
> > max_mem_size. We will get errors like:
> > 
> > [  216.387164] acpi PNP0C80:02: add_memory failed
> > [  216.389301] acpi PNP0C80:02: acpi_memory_enable_device() error
> > [  216.392187] acpi PNP0C80:02: Enumeration failure
> > 
> > This will cause issue in a known use case where 'mem=' is added to
> > the hypervisor. The memory that lies after 'mem=' boundary will be
> > assigned to KVM guests. After commit 357b4da50a62 merged, memory
> > can't be extended dynamically if system memory on hypervisor is not
> > sufficient.
> > 
> > So fix it by also checking if it's during boot-time restricting to add
> > memory. Otherwise, skip the restriction.
> > 
> > And also add this use case to document of 'mem=' kernel parameter.
> > 
> > Fixes: 357b4da50a62 ("x86: respect memory size limiting via mem= parameter")
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> 
> Reviewed-by: Juergen Gross <jgross@suse.com>

Thanks, Juergen. Seems I should add more details to explain this. Will
post v4 with your 'Reviewed-by'.



  reply	other threads:[~2020-02-06  2:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04  5:06 [PATCH v3] mm/hotplug: Only respect mem= parameter during boot stage Baoquan He
2020-02-04  7:53 ` Jürgen Groß
2020-02-06  2:58   ` Baoquan He [this message]
2020-02-06  8:55 ` David Hildenbrand
2020-02-06  9:44   ` Baoquan He
2020-02-14 10:53 ` Michal Hocko

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=20200206025843.GL8965@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bsingharora@gmail.com \
    --cc=david@redhat.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    /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.