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_wip [2017/04/26 23:03] jithu minor stuff |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== RT App memory related ====== | ||
- | **(Currently WIP (Work in Progress), Ignore the contents until this line is removed )** | ||
- | This page is meant to document the things to be considered from a Real Time Application's memory perspective. The following things fall into the purview of this topic: | ||
- | - Memory Locking | ||
- | - Stack Memory allocation and prefaulting | ||
- | - Dynamic memory allocation and prefaulting | ||
- | Keep in mind that the [[realtime:documentation:howto:applications:application_base|usual sequence]] is for an app to begin its execution as a regular(non RT) App, then create the RT threads with appropriate resources and scheduling parameters. | ||
- | |||
- | ===== Memory Locking ===== | ||
- | Through the ''mlockall()'' system-call, it is possible for an app to instruct the kernel to lock the calling process's entire virtual address space - current and future - into RAM, thereby preventing it from being paged to the swap during the process's lifetime. See the snippet below: | ||
- | <code c> | ||
- | /* Lock all current and future pages from preventing of being paged to swap */ | ||
- | if (mlockall( MCL_CURRENT | MCL_FUTURE )) | ||
- | { | ||
- | perror("mlockall failed"); | ||
- | } | ||
- | </code> | ||
- | |||
- | Real-time apps should do this at first (i.e prior to spawning the real-time threads), since, memory access latency of a paged-out address will be significantly worse (than if it is present in the RAM). Consequently, failing to do so will significantly affect the determinism based on the overall system's memory pressure. | ||
- | |||
- | Note that this call would be applicable for all memoriy areas in the address space - i.e globals, stack, heap, code etc |