On 08/26/2011 10:54 PM, Jeremy Friesner wrote:
> I suspect that is has something to do with mlockall() and/or some
> other aspect of Xenomai partially or fully defeating the fork()
> call's Copy-On-Write feature, meaning that when the sub-process is
> spawned, most or all of the RAM pages allocated by the parent process
> are being duplicated, even though they are all going to be thrown
> away again immediately because I'm going to call exec() right
> afterwards.
The "copy-on-write" feature causes faults both in the parent and child
process, which causes threads to exit primary mode. So, in order to
avoid it, we duplicate the memory space when forking.
>
> My question is, is there some recommended way to launch a sub-process
> from a large Xenomai process that will avoid massive amounts of
> overhead? I suppose I could launch a separate, persistent,
> non-Xenomai process that would act as a "non-Xenomai process server",
> and connect to it via TCP and ask it to spawn processes on my
> behalf.... but that seems like an awful lot of extra work. Is there
> an easier way around this problem?
If what you intend is to execute another thread, you do not need to use
fork(), you can use vfork() which will avoid the issue you are
mentioning. Normally, if you are using a recent libc, system() already
uses vfork().
It is also worth mentioning that the reason why your process consumes so
much memory in the first place may be because of the space allocated for
the threads stacks (2MB by default), because of mlockall. So, if you are
using the posix API, think about setting the stacks sizes to a more
reasonable size with pthread_attr_setstacksize.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
