User Tools

Site Tools


realtime:documentation:howto:applications:memory

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
realtime:documentation:howto:applications:memory [2017/07/15 00:16]
jithu [Dynamic memory allocation for RT usage] - review comm - wip
realtime:documentation:howto:applications:memory [2017/07/15 02:25] (current)
jithu [Memory Locking]
Line 8: Line 8:
 ===== Memory Locking ===== ===== Memory Locking =====
 Memory locking APIs allow an application to instruct the kernel to associate (some or all of its) virtual memory pages with real page frames and keep it that way. In other words : Memory locking APIs allow an application to instruct the kernel to associate (some or all of its) virtual memory pages with real page frames and keep it that way. In other words :
-  * Memory locking ​calls will trigger the necessary page-faults to bring in the pages being locked to physical memory ​and populates the application'​s page-table with the corresponding entries. Consequently first access to a locked-memory (following an ''​mlock*()''​ call) will already have physical memory assigned and will not page fault (in  RT-critical path) thus removing ​the need to explicitly pre-fault ​the memory ​otherwise+  * Memory locking ​APIs will trigger the necessary page-faultsto bring in the pages being lockedto physical memory. Consequently first access to a locked-memory (following an ''​mlock*()''​ call) will already have physical memory assigned and will not page fault (in  RT-critical path). This removes ​the need to explicitly pre-fault ​these memory. ​
   * Further memory locking prevents an application'​s memory pages, from being paged-out, anytime during its lifetime even in when the overall system is facing memory pressure.   * Further memory locking prevents an application'​s memory pages, from being paged-out, anytime during its lifetime even in when the overall system is facing memory pressure.
  
Line 14: Line 14:
 [[http://​www.gnu.org/​software/​libc/​manual/​html_node/​Locking-Pages.html|The GNU C Library: Locking pages]]. Note that these calls requires the application to have sufficient privileges (i.e.  [[http://​man7.org/​linux/​man-pages/​man7/​capabilities.7.html|CAP_IPC_LOCK capability]]) to succeed. [[http://​www.gnu.org/​software/​libc/​manual/​html_node/​Locking-Pages.html|The GNU C Library: Locking pages]]. Note that these calls requires the application to have sufficient privileges (i.e.  [[http://​man7.org/​linux/​man-pages/​man7/​capabilities.7.html|CAP_IPC_LOCK capability]]) to succeed.
  
-While ''​mlock(<​addr>,​ <​length>​)''​ locks specific pages (described by //address// and //​length//​),​ ''​mlockall(...)''​ locks an application'​s entire virtual address space (i.e [[realtime:​documentation:​howto:​applications:​memory:​mlockall_globals_sample|globals]], ​[[realtime:​documentation:​howto:​applications:​memory:​mlockall_stack_sample|stack]], heap, code) in physical memory. The trade-off between convenience and locking-up excess RAM should drive the choice of one over the other. Locking only those areas which are accessed by RT-threads (using ''​mlock(...)''​) could be cheaper than blindly using ''​mlockall(...)''​ which will end-up locking all memory pages of the application (i.e. even those which are used only by non-RT threads).+While ''​mlock(<​addr>,​ <​length>​)''​ locks specific pages (described by //address// and //​length//​),​ ''​mlockall(...)''​ locks an application'​s entire virtual address space (i.e [[realtime:​documentation:​howto:​applications:​memory:​mlockall_globals_sample|globals]],​ stack, heap, code) in physical memory. The trade-off between convenience and locking-up excess RAM should drive the choice of one over the other. Locking only those areas which are accessed by RT-threads (using ''​mlock(...)''​) could be cheaper than blindly using ''​mlockall(...)''​ which will end-up locking all memory pages of the application (i.e. even those which are used only by non-RT threads).
  
  
Line 56: Line 56:
  
  
-=====  Dynamic memory allocation ​for RT usage =====+=====  Dynamic memory allocation ​in RT threads=====
  
-The suggested recommendation ​is for the RT threads to do malloc() and free() outside of its real-time critical ​phase.+Real-time threads should avoid doing dynamic memory allocation / freeing while in RT critical path. The suggested recommendation for real-time ​threads, is to do the allocations,​ prior-to entering RT critical ​path. Subsequently RT threads, within their RT-critical path, can use this pre-allocated dynamic memory, provided that it is locked as described [[memory#​Memory Locking|here]]. 
 + 
 +Non RT-threads within the applications have no restrictions on dynamic allocation / free
  
realtime/documentation/howto/applications/memory.1500077815.txt.gz · Last modified: 2017/07/15 00:16 by jithu