Re: [PATCH] mm: fix movable_node kernel command-line

[Michal Hocko <mhocko@kernel.org>]

On Mon 23-10-17 18:06:33, Sharath Kumar Bhat wrote:
> 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.

absolutely agreed!

> > > 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.

Do you have any specific architecture in mind?

> 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.

This is true and in fact movable_node should become movable_memory over
time and only ranges marked as movable would become really movable. This
is a rather non-trivial change to do and there is not a great demand for
the feature so it is low on my TODO list.

> 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.

This is something you have to do anyway when the topology of the system
changes each boot.

That being said, I would really prefer to actually _remove_ kernel_core
parameter altogether. It is messy (just look at find_zone_movable_pfns_for_nodes
at al.) and the original usecase it has been added for [1] does not hold
anymore. Adding more stuff to workaround issues which can be handled
more cleanly is definitely not a right way to go.

[1] note that MOVABLE_ZONE has been originally added to help the
fragmentation avoidance.
-- 
Michal Hocko
SUSE Labs

--
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>