http://elinux.org/Memory_ManagementMemory ManagementFrom eLinux.orgThis page has information about various memory management projects and activities which are of interest to embedded Linux developers.
Areas of InterestMost 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. Memory MeasurementAnalyzing the amount of system memory in use and available is trickier than it sounds.
Huge/large/superpages
Page cache compression
Reserving (and accessing) the top of memory on startupA 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) handlingSeveral 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 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 instead of memory mapped, it's less likely to help because of heap fragmentation and it requiring more work/time though.
Type-based memory allocation (old)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 Additional Resources/Mailing Lists
|
