From: Sharath Kumar Bhat <sharath.k.bhat@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: sharath.k.bhat@linux.intel.com, Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org, akpm@linux-foundation.org
Subject: Re: [PATCH] mm: fix movable_node kernel command-line
Date: Mon, 23 Oct 2017 18:06:33 -0700 [thread overview]
Message-ID: <20171024010633.GA2723@linux.intel.com> (raw)
In-Reply-To: <0ed8144f-4447-e2de-47f7-ea1fc16f0b25@intel.com>
On Mon, Oct 23, 2017 at 02:52:04PM -0700, Dave Hansen wrote:
> On 10/23/2017 12:56 PM, Sharath Kumar Bhat wrote:
> >> I am sorry for being dense here but why cannot you mark that memory
> >> hotplugable? I assume you are under the control to set attributes of the
> >> memory to the guest.
> > When I said two OS's I meant multi-kernel environment sharing the same
> > hardware and not VMs. So we do not have the control to mark the memory
> > hotpluggable as done by BIOS through SRAT.
>
> If you are going as far as to pass in custom kernel command-line
> arguments, there's a bunch of other fun stuff you can do. ACPI table
> overrides come to mind.
>
> > This facility can be used by platform/BIOS vendors to provide a Linux
> > compatible environment without modifying the underlying platform firmware.
>
> https://www.kernel.org/doc/Documentation/acpi/initrd_table_override.txt
I think ACPI table override won't be a generic solution to this problem and
instead would be a platform/architecture dependent solution which may not
be flexible for the users on different architectures. And moreover
'movable_node' is implemented with an assumption to provide the entire
hotpluggable memory as movable zone. This ACPI override would be against
that assumption. Also ACPI override would introduce additional topology
changes. Again this would have to change every time the total movable
memory requirement changes and the whole system and apps have to be
re-tuned (for job launch ex: numactl etc) to comphrehend this change.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-10-24 1:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 23:32 Sharath Kumar Bhat
2017-10-23 12:52 ` Michal Hocko
2017-10-23 16:03 ` Sharath Kumar Bhat
2017-10-23 16:15 ` Michal Hocko
2017-10-23 17:14 ` Sharath Kumar Bhat
2017-10-23 17:20 ` Michal Hocko
2017-10-23 17:35 ` Sharath Kumar Bhat
2017-10-23 17:49 ` Michal Hocko
2017-10-23 18:48 ` Sharath Kumar Bhat
2017-10-23 19:04 ` Michal Hocko
2017-10-23 19:25 ` Sharath Kumar Bhat
2017-10-23 19:35 ` Michal Hocko
2017-10-23 19:56 ` Sharath Kumar Bhat
2017-10-23 21:52 ` Dave Hansen
2017-10-24 1:06 ` Sharath Kumar Bhat [this message]
2017-10-24 7:19 ` Michal Hocko
2017-10-25 0:53 ` Sharath Kumar Bhat
2017-10-25 6:38 ` Michal Hocko
2017-10-25 22:01 ` Sharath Kumar Bhat
2017-10-26 7:36 ` 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=20171024010633.GA2723@linux.intel.com \
--to=sharath.k.bhat@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox