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

[Sharath Kumar Bhat <sharath.k.bhat@linux.intel.com>]

On Wed, Oct 25, 2017 at 08:38:52AM +0200, Michal Hocko wrote:
> 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:
> > > On Mon 23-10-17 18:06:33, Sharath Kumar Bhat wrote:
> [...]
> > > > 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.

Ok then I believe it will let user to specify multiple memory ranges so
that admin can explicitly choose to have movable zones in either
hotpluggable or non-hotpluggable memories. Because in this use case the
requirement is to have the movable zones in both hotpluggable and
non-hotpluggable memories.

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

Right its not about movability, since 'movable_node' assumes that the entire
memory node is hotpluggable, to stay compatible with it the memory ranges of
non-hotpluggable memory that we want to be movable zone should be exposed as
a complete node. This increases the number of NUMA nodes and the total
no.of such nodes changes as the movable memory requirement changes.

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

I thought you mentioned its a low priority on the TODO list and you
dont expect to see it in the near future. So till then there is no
existing solution that one case use.

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