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

On Tue 24-10-17 17:53:14, Sharath Kumar Bhat wrote:

On Tue, Oct 24, 2017 at 09:19:06AM +0200, Michal Hocko wrote:

quoted

On Mon 23-10-17 18:06:33, Sharath Kumar Bhat wrote:

[...]

quoted

quoted

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.

Do you mean to have a single kernel command-line 'movable_memory=' for this
purpose and remove all other kernel command-line parameters such as
'kernelcore=', 'movablecore=' and 'movable_node'?

yes.

because after the kernel
boots up we can not gurantee that a contig memory range can be made zone
movable since any kernel allocations could pre-exist.

No, I meant that the zone association would be done _only_ based by
memory attributes exported by ACPI or whatever is used to configure
memory ranges on the particular platform. So an early init code.

quoted

quoted

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.

No, this is a manual tuning for job-launch, mem policy handling code etc.
which would be done once for a platform. But in this case based on the
application need the amount of movable memory will change so it is really
unfair to ask user to re-work their job launch and apps for every such
changes.

I am still confused. Why does the application even care about
movability?
 

quoted

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.

I agree that kernelcore handling is non-trivial in that function. But the
changes introduced by this patch are under 'movable_node' case handling in
find_zone_movable_pfns_for_nodes() and it does not cause any change to the
existing kernelcore behavior of the code. Also this enables all
multi-kernel users to make use of this functionality untill later when
new interface would be available for the same purpose.

The point is to not build on top and rather get rid of it completely.
 

quoted

[1] note that MOVABLE_ZONE has been originally added to help the
fragmentation avoidance.

Isn't this true even now since ZONE_MOVABLE will populate only
MIGRATE_MOVABLE free list of pages? and other zones could have
MIGRATE_UNMOVABLE pages?

My point was that the original motivation is gone because our compaction
code doesn't really depend on movable zone. So the movable zone is more
about making sure that the specific memory is migratable and so
offlineable.

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