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