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

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