[Simgrid-user] Excessive Memory Use
wkolberg at inf.ufrgs.br
Sat Jul 23 16:38:53 CEST 2011
It seems that we have found the problem! Using the
SIMIX_process_empty_trash() function did the trick.
And you are absolutely right, I guess that simgrid's non-blocking
functions like MSG_task_isend() will solve my problem without spawning
new processes, my bad. And that will probably use even less memory?
So thank you for your effort and cooperation.
On Fri, Jul 22, 2011 at 8:52 PM, Martin Quinson <martin.quinson at loria.fr> wrote:
> It seems that you trigered a bug in the recent rewrite of SIMIX. We
> forget to clean the terminated processes until the very end of the
> simulation. Try calling
> somewhere in your code to see whether it helps (just add a fake
> prototype in your code if you need to, that's an internal function
> which does not live in any public header). This function is in charge
> of freeing the context of dead processes.
> I'd say that in previous version it was called in each scheduling
> round (ie main loop of the simulator), and now the only remaining call
> is in SIMIX_process_killall(), itself only called from SIMIX_clean().
> I think we found your bug (in our code, sorry). Now. Why the heck are
> you spawning a process per communication? I fear that it's to achieve
> non blocking communication. If so, you may want to switch to
> MSG_task_isend(), MSG_task_irecv(), MSG_task_test() and
> MSG_task_wait(). Before you ask, MSG_task_dsend() is a detached send
> where you send the data in best effort and don't care of whether it
> gets received or raises an error (see the chord example). And
> MSG_task_isend_with_matching() allows to mimick the MPI tag mechanism.
> Thanks for your time,
> Those are my principles, and if you don't like them... well, I have others.
> -- Groucho Marx
> Simgrid-user mailing list
> Simgrid-user at lists.gforge.inria.fr
More information about the Simgrid-user