Hi Gilles, Thanks, your suggestions were very helpful. I reduced my threads' stack sizes as you suggested, and the RAM usage of my test dropped from 55% to 17%! :^) This made the overhead of the fork() call correspondingly smaller, so perhaps I can ignore that overhead for now.
Jeremy On Aug 26, 2011, at 2:04 PM, Gilles Chanteperdrix wrote: > 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 Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
