[linux-audio-dev] the stack threat - memory management and RT apps

[Christian Schoenebeck]

Es geschah am Sonntag 29 Mai 2005 23:46 als fons adriaensen schrieb:
> True, arguments (and local variables) live on the stack, but normally
> they should not take too much space. The thing to avoid is functions
> that have large local arrays or objects, and this is almost always
> possible.

Well, the usual (low) stack size occupation is not an argument to me. In a 
long development process things usually become complex and thus the calling 
chain may grow and even worse..... may strongly vary during execution.

Es geschah am Montag 30 Mai 2005 00:49 als Paul Davis schrieb:
> alternatively, allocate a huge stack based object early in the
> thread's life (preferably before RT-ness matters). if mlockall() has
> been called, any pages allocated to the stack will remain locked in
> physical RAM. problem solved.

That was also my assumption, but I wanted to know it for certain. Because the 
question was if "freed" pages were locked as well. Anyway I just noticed that 
simply reading the mlockall() man page clearifies this question:

 "Real-time processes should reserve enough locked stack pages before entering
  the time-critical section, so that no page fault can be caused by function 
  calls. This can be achieved by calling a function which has a sufficiently 
  large automatic variable and which writes to the memory occupied by this 
  large array in order to touch these stack pages. This way, enough pages will  
  be mapped for the stack and can be locked into RAM. The dummy writes ensure 
  that not even copy-on-write page faults can occur in the critical section."

CU
Christian