• Jamboree18Cabi

[original file is memo_ja-CABI_Memory_management.txt]
[translated by ikoma]

CELF Technical Jamboree #18
Dec. 21, 2007
============================================================
CELF Technical Jamboree #18

• Implementation of Memory Management for Embedded Systems

============================================================

Implementation of Memory Management for Embedded Systems

by Miyake, Lineo

* CABI

* Background

• Embedded systems also shifting to dynamic memory allocation systems due to diversifying applications and multitasks
  • Software bug can use up memory to cause important application get short of memory or the entire system get unreliable

* Memory management issues on embedded systems

• swap taken for granted (for servers)
  • Behavior at memory starvation is troublesome (OOM Killer)
• Page cache issue
  • All of free area is used as page cache
    • Cannot manage contiguous physical memory
• Process group management

* Proposal

• To limit the memory usage for unimportant processes to ensure memory for imporant applications
• To limit the assignable physical memory amount including page cache; to notify if it exceeds certain level

* Software structure

• Accounting/process binding function
  • CABI

    • Manage resouces (memory, CPU) to use by binding more than one process to AO (AccountingObject)

  • Processes registerable/deletable to AO (binding)
• Memory Management
  • Manage the total number of page frames used by processes on an AO
    • Mapping frames (mmap, malloc, etc.), page cache created by processes (file R/W)
  • When upper limit or alarming level reached, memory allocation is blocked and the event is notified to the application (page recollection, singal sending, select wakeup)
• Event management function
  • PID of management process is registered on AO beforehand
• procfs function
  • Management information of memory resource referrable
    • Fixed so that proc-to-page mapping status can be displayed
    • Per AO information
    • Per process information

* Modification of CABI

• Original CABI manages CPU resouces; memory resource management function is added to resouce management common part

* Q&A

• You presented that page collection collects pages in the same AO; how does it actually work?
  • Implemented in applications
• Why didn't you improve OOMKiller but used CABI?
  • Because CABI was a proved technolgy and process grouping per priority seemed necessary.

• What is the impact if everything is implemented in multitasks in embedded systems?
  • When a process is generated, AO is automatically assigned and the process is put under its control; I believe theoretically no problem
  • When implemented on NUMA, is it designed so that nearer memory is allocated?
    • Not implemented yet; in general we use no tricks, so it could be supported if a mechanism to count memory usage and to make decision is incorporated in NUMA
  • If an AO occupies 5MB, other processes can not use it?
    • Processes to which no AO is assigend can use other memory
  • This is designed to limit upper bound, but managing lower limit would bring wider application area.
  • The idea to manage page compaction in AO would lead to intresting technology
  • How much improvemnet is expected for contiguous physical memory allocation?
    • Contiguous momory allocation can not be garranteed, but expected to be improved
  • Does page cache recollection take physical memory contiguity into consideration?
    • No at the moment; it might cause further fragmentation