[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
Received on Sun May 29 20:15:14 2005