30 May
2005
30 May
'05
10:57 p.m.
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