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
Received on Tue May 31 04:15:11 2005
This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 04:15:11 EEST