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: > > 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? There are no such restrictions related to architectures that we can run on though we are currently testing on KNL, Xeon. > > > 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'? 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. > > > 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. > > 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. > > [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? -- 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>
