From: eLinux.org
This page has information about various memory management projects and activities which are of interest to embedded Linux developers.
Most of these areas have wider reaching implications, but are 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.
Analyzing the amount of system memory in use and available is trickier than it sounds.
See Runtime Memory Measurement for different methods of measuring and analyzing system memory.
See Accurate Memory Measurement for some different techniques for dealing with inadequacies in current memory measurement systems.
See Tims Notes on ARM memory allocation for some ARM-specific memory management information.
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);
Several technologies have been developed and suggested for improving the handling Out-Of-Memory (OOM) 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 technologies that I know about (these need to be researched and documented better):
User "oak" writes (commenting on the mem_notify patches):
Posted Feb 3, 2008 14:02 UTC (Sun) by oak (guest, #2786) [Link]
...
I thought the point of the patch is for user-space to be able to do the
memory management in *manageable places* in code. As mentioned earlier,
a lot of user-space code[1] doesn't handle memory allocation failures. And
even if it's supposed to be, it can be hard to verify (test) that the
failures are handled in *all* cases properly. If user-space can get a
pre-notification of a low-memory situation, it can in suitable place in
code free memory so that further allocations will succeed (with higher
propability).
That also allows doing somehing like what maemo does. If system gets
notified about kernel low memory shortage, it kills processes which have
notified it that they are in "background-killable" state (saved their UI
state, able to restore it and not currently visible to user). I think it
also notifies applications (currently) through D-BUS about low memory
condition. Applications visible to user or otherwise non-background
killable are then supposed to free their caches and/or disable features
that could take a lot of additional memory. If the caches are from [[Heap_memory|heap]]
instead of memory mapped, it's less likely to help because of [[Heap_memory|heap]]
fragmentation and it requiring more work/time though.
This is a mechanism (prototyped in the 2.4 kernel by Sony and Panasonic) to allow the kernel to allocate different types of memory for different sections of a program, based on user policy.
See Memory Type Based Allocation
LinuxMM - links to various sub-projects, and acts as a centralized point for discussion relating to memory management topics (linux-mm mailing list and archives).
Excellent paper (2010) by Paul McKenney on how CPU caches operate