Today, we are increasingly seeing computer systems sporting larger and larger amounts of RAM, in order to meet workload demands. However, memory consumes a significant amount of power, potentially upto more than a third of total system power on server systems. So naturally, memory becomes the next big target for power management - on embedded systems and smartphones, and all the way upto large server systems. Modern memory hardware such as DDR3 support a number of power management capabilities. And new firmware standards such as ACPI 5.0 have added support for exposing the power-management capabilities of the underlying memory hardware to the Operating System. So it is upto the kernel's MM subsystem to make the best use of these capabilities and manage memory power-efficiently. It had been demonstrated on a Samsung Exynos board (with 2 GB RAM) that upto 6% of total system power can be saved by making the Linux kernel MM subsystem power-aware[1]. (More savings can be expected on systems with larger amounts of memory, and perhaps improved further using better MM designs). Often this simply translates to having the Linux MM understand the granularity at which RAM modules can be power-managed, and consolidating the memory allocations and references to a minimum no. of these power-manageable "memory regions". It is of particular interest to note that most of these memory hardware have the intelligence to automatically save power, such as putting memory banks into (content-preserving) low-power states when not referenced for a threshold amount of time. All that the kernel has to do, is avoid wrecking the power-savings logic by scattering its allocations and references all over the system memory. IOW, the kernel/MM doesn't really need to keep track of memory DIMMs and perform their power-state transitions - most often it is automatically handled by the hardware/memory-controller. The MM has to just co-operate by keeping the references consolidated to a minimum no. of memory regions. To that end, I had recently posted patchsets implementing 2 very different MM designs, namely the "Hierarchy" design[2] (originally developed by Ankita Garg) and the new "Sorted-buddy" design[3]. The challenge with the latter design is that it can potentially lead to increased run-time memory allocation overheads. At the summit, I would like to brainstorm on ideas and designs for reducing the run-time cost of implementing memory power management, and seek suggestions and feedback from MM developers on the issues involved. About myself: ------------ I have been contributing to CPU- and System-wide power management subsystems in the kernel such as CPU idle and Suspend-to-RAM, in terms of enhancements to their reliability/scalability. In particular, I have contributed to some of the core kernel infrastructure that Suspend-to-RAM depends on, such as Freezer and CPU hotplug, and have been working towards redesigning CPU hotplug to get rid of some of its pain points. Recently I have been looking at conserving memory power, and came up with the "Sorted-buddy" design [3] of the Linux MM, which alters the buddy allocator to keep memory allocations consolidated to a minimum no. of memory regions. I would like to discuss this topic with other MM developers at the summit and get feedback on the best way to take this technology forward. References: ---------- 1. Estimate of potential power savings on Samsung exynos board http://article.gmane.org/gmane.linux.kernel.mm/65935 2. "Hierarchy" design for Memory Power Management: http://lwn.net/Articles/445045/ (Original posting by Ankita Garg) http://lwn.net/Articles/523311/ (Forward-port to 3.7-rc3) 3. "Sorted-buddy" design for Memory Power Management: http://article.gmane.org/gmane.linux.power-management.general/28498/ Regards, Srivatsa S. Bhat -- 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>