[Ksummit-2013-discuss] [ATTEND] Linux VM Infrastructure to support Memory Power Management

Yasuaki Ishimatsu isimatu.yasuaki at jp.fujitsu.com
Wed Jul 24 01:09:21 UTC 2013


(2013/07/19 17:26), Kamezawa Hiroyuki wrote:
> (2013/07/18 20:59), Srivatsa S. Bhat wrote:
>>
>> [By mistake, I had sent this mail to 2012's Kernel Summit list.
>> Resending it to 2013's Kernel Summit mailing list now.]
>>
>>
>
> Ishimatu-san (a memory hotplug guy), how do you think ?

I'm interested in this topic.

Our work is to support memory hotplug. One of purposes of the work is to
save the power. But memory hotplug operation needs a time at BIOS and OS for
managing added/removed memory device. So if user changes memory status
for saving the power repeatedly, using memory hotplug is not convenient.

I think that one of the solution to save the power is Memory Power Management.

So I would like to attend and discuss the topic.

Thanks,
Yasuaki Ishimatsu

> -Kame
>> Hi,
>>
>> I have been working on developing Linux VM designs and algorithms to support
>> Memory Power Management. As computer systems are increasingly sporting larger
>> and larger amounts of RAM, the power consumption of the memory hardware
>> subsystem is showing up as a very significant portion of the total power
>> consumption of the system (sometimes even higher than that of CPUs, depending
>> on the machine configuration)[2]. So memory has become an important target
>> for power-management - on embedded systems/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
>> to export the power-management features of the underlying memory hardware
>> to the Operating System in a standard way[3]. And on ARM platforms this info
>> can be exported to the OS via the bootloader or the device-tree. So ultimately,
>> 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[4]. (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 number of these power-manageable
>> "memory regions". The memory hardware has the intelligence to automatically
>> transition memory banks that haven't been referenced for a threshold amount
>> of time, to low-power content-preserving states. And they can also perform
>> OS-cooperative power-down of unused (unallocated) memory regions. So the onus
>> is on the Linux VM to become power-aware and shape the allocations and
>> influence the references in such a way that it helps conserve memory power.
>> This involves consolidating the allocations/references at the right address
>> boundaries, keeping the memory-region granularity in mind.
>>
>> With that goal, I had revived Ankita Garg's "Hierarchy" design of the
>> Linux VM[5] and later I had come up with a completely new design called the
>> "Sorted-buddy" design[6]. Recently, I also added a mechanism to perform targeted
>> memory compaction, in order to support light-weight memory region evacuation,
>> to further enhance the opportunities for memory power savings[7]. While these
>> patchsets did generate a fair amount of discussion around the issues involved,
>> the implications of these core MM changes can be quite far-reaching and hence
>> I believe that having a wider discussion in the Kernel Summit would be
>> invaluable and would help convey the idea behind this work and get insights
>> and suggestions from core developers and maintainers.
>>
>> (At the same time, I'm working on addressing the review comments/suggestions
>> received on these designs, and I'll be posting a new version soon).
>>
>>
>> I would very much appreciate the opportunity to discuss this topic with
>> core MM developers/maintainers like Andrew Morton, Mel Gorman, Dave Hansen,
>> et al., and also seek platform-level insights and feedback from people like
>> Matthew Garrett, Arjan Van de Ven, Srinivas Pandruvada, Len Brown and others.
>>
>>
>> Thank you very much!
>>
>>
>> References:
>> ----------
>>
>> [1]. LWN article that explains the goals and the design of my Memory Power
>>       Management patchset:
>>       http://lwn.net/Articles/547439/
>>
>>
>> [2]. C. Lefurgy, K. Rajamani, F. Rawson, W. Felter, M. Kistler, and
>>       Tom Keller.
>>       Energy management for commercial servers. In IEEE Computer, pages 39–48,
>>       Dec 2003.
>>       Link: researcher.ibm.com/files/us-lefurgy/computer2003.pdf
>>
>> [3]. ACPI 5.0 and MPST support
>>       http://www.acpi.info/spec.htm
>>       Section 5.2.21 Memory Power State Table (MPST)
>>
>> [4]. Estimate of potential power savings on Samsung exynos board
>>       http://article.gmane.org/gmane.linux.kernel.mm/65935
>>
>> [5]. "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)
>>
>> [6]. "Sorted-buddy" design for Memory Power Management:
>>       http://article.gmane.org/gmane.linux.power-management.general/28498/
>>
>> [7]. v2 of the "Sorted-buddy" patchset with support for targeted memory
>>       region compaction:
>>       http://lwn.net/Articles/546696/
>>
>>       LWN article describing this design: http://lwn.net/Articles/547439/
>>
>> [7]. Prototype implementation of parsing ACPI 5.0 MPST tables, by Srinivas
>>       Pandruvada.
>>       https://lkml.org/lkml/2013/4/18/349
>>
>>
>> Regards,
>> Srivatsa S. Bhat
>>
>
>




More information about the Ksummit-2013-discuss mailing list