This page has information about various memory management projects and activities which are of interest to embedded Linux developers.
Areas of Interest
Most of these areas have wider reaching implications, but are of relatively simpler in the embedded case, largely thanks to not having to contend with swap and things of that nature. Simpler memory management as well as vendors not afraid of deviation from mainline for product programs makes for an excellent playground for experimenting with new things in the memory management and virtual memory space.
- This applies to both transparent large page usage as well as the more static usage models, primarily relating to work outside of the hugetlb interface/libhugetlbfs.
- Embedded systems suffer from very small TLBs generally using PAGE_SIZE'd pages (4kB) for coverage. In most cases this places the system under very heavy pressure for any kind of userspace work, and very visibly degrading performance, with most applications taking anywhere from 5-40% of their time on the CPU servicing page faults.
- Preliminary discussion on this subject as well as links to additional information is happening through the wiki here: Huge Pages
Page cache compression
- This relates to using various compression algorithms for performing run-time compression and decompression of page cache pages, specifically aimed at both reducing memory pressure as well as helping performance in certain workloads.
- More information can be found on the wiki here CompressedCaching as well as at the SF Compressed Caching home page.
Reserving (and accessing) the top of memory on startup
A quote from Todd's email on how to use the reserved physical memory in "mem=".
Given that you have a fixed address for your memory, and is already reserved, the easier way to use it is by calling mmap() over the /dev/ mem device, use 0 as the start address, and the physical address of the reserved memory as the offset. The flags could be MAP_WRITE| MAP_READ. That will return you a pointer on user space for your memory mapped by the kernel. For example
If your SDRAM base address is 0x80000000 and your memory is of 64MB, but you use the cmdline mem=60M to reserve 4MB at the end. Then your reserved memory will be at 0x83c00000, so all you need to do is
int fd; char *reserved_memory; fd = open("/dev/mem",O_RDWR); reserved_memory = (char *) mmap(0,4*1024*1024,PROT_READ| PROT_WRITE,MAP_SHARED,fd,0x83c00000);
Enhanced Out-Of-Memory (OOM) handling
Several technologies have been developed and suggested for improving the handling out-of-memory conditions with Linux systems.
See http://linux-mm.org/OOM_Killer for information about the OOM killer in the Linux kernel.
Part of OOM avoidance is for the kernel to have an accurate measure of memory utilization. See Accurate Memory Measurement for information on technology in this area.
Here are some I know about (these need to be researched and documented):
- Nokia OOM enhancements in Maemo
- Referenced at: http://lwn.net/Articles/267013/ (search for "Nokia" in the comments)
- Paul Mundt submitted a patch to CELF for the 2.6 kernel which provided low-memory notifications to user space. See Accurate_Memory_Measurement#Nokia_out-of-memory_notifier_module for more information.
- This module was based on the Linux Security Module system, which has been removed from recent kernels.
- Google per-cgroup OOM handler
- Google posted a Request For Comments (RFC) for OOM handling implemented in a per-cgroup fashion. See http://article.gmane.org/gmane.linux.kernel.mm/28376
- mem_notify patches
- This set of patches provided a mechanism to notify user-space when memory is getting low, allowing for application-based handling of the condition. These patches were submitted in January 2008.
- See http://lwn.net/Articles/267013/