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. > 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? > > 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. > > [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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
