realtime:documentation:howto:applications:memory
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
realtime:documentation:howto:applications:memory [2017/07/15 01:56] jithu [Memory Locking] |
realtime:documentation:howto:applications:memory [2017/07/15 02:25] 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 APIs 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-faults, to bring in the pages being locked, to 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 58: | Line 58: | ||
| ===== Dynamic memory allocation in RT threads===== | ===== Dynamic memory allocation in RT threads===== | ||
| - | 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 memory, provided that it is locked as described [[memory#Memory Locking|here]] . | + | 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 . | + | 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
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
