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
Next revision Both sides next revision
realtime:documentation:howto:applications:memory [2017/07/15 00:43]
jithu [Dynamic memory allocation for RT usage] - review comm - wip
realtime:documentation:howto:applications:memory [2017/07/15 01:55]
jithu [Memory Locking]
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=====
  
-Real-time threads should avoid doing dynamic memory allocation/ free while in RT critical path. The suggested recommendation is  to do the allocations before entering RT critical path. It is okay for the RT thread to access ​this memory ​while in RT phase provided that it is locked ​using mlock(). Non RT-threads within the applications have no restrictions on dynamic allocation / free . +Real-time threads should avoid doing dynamic memory allocation / free while in RT critical path. The suggested recommendation ​for real-time threads ​is to do the allocations before entering RT critical path. It is okay for the RT thread ​in RT critical path to access ​a dynamically allocated ​memoryprovided 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.txt · Last modified: 2017/07/15 02:25 by jithu