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

[Christian Schoenebeck]

Hi!

I guess everybody of you know that allocating memory on the heap at runtime in 
RT threads is not a good idea. This can easily prevented by user space / 
application managed memory pools.

But whatabout the stack? Even if you try to use the heap for local variables 
as well, you (usually) won't be able to prevent usage of the stack due to ABI 
definitions; e.g. on most platforms function arguments will be delivered 
through the stack. So what can you do to prevent physical pages to be 
allocated for the stack at RT critical time? Because this would lead to the 
same problems as calling malloc(), new and co.

I read: "Although it is possible to give memory back to the system and shrink 
a process's address space, this is almost never done." [1] That sounds to me 
as once physical memory pages were assigned to the virtual stack range (due 
to stack growth), those physical pages were not be freed even if the virtual 
stack shrinks (that is the stack pointer increments). Is that true? And what 
does "almost" mean in this manner? Unfortunately I'm not into the mm 
internals of Linux yet.

If the above claim is true, then we could simply increase the stack for a 
short time at the beginning of a RT application, e.g. by calling alloca() 
(maybe not good - dangerous and not portable) or by defining a big array on 
the stack in a helper function and/or by making that helper function recurse 
to a certain level to solve the danger of the stack.

Anybody with deep Linux mm knowledge around?

CU
Christian

[1] http://www.informit.com/articles/article.asp?p=173438