[Simgrid-user] Excessive Memory Use

Bruno Donassolo bruno.donassolo at gmail.com
Thu Jul 21 17:24:04 CEST 2011


Hi,

Just a little help...

On Thu, Jul 21, 2011 at 12:00 PM, Wagner Kolberg <wkolberg at inf.ufrgs.br>wrote:

> Hi, I'm working on this same project and I'll try to explain what we are
> doing in our code, so we can solve the problem.
>
> That's the THROW_IMPOSSIBLE which leaks. So, you are experiencing a
>> part of the code which is not tested, and you're hiding the abort
>> message. I guess that you have a try/catch in your code swallowing
>> exceptions, in finish_all_task_copies (master.c:573)
>>
>> This bug report is precious to me, and I'd really appreciate if you
>> could give me what's needed to reproduce and investigate myself.
>>
>
> Ok, so... to model our system, we create some tasks that are supposed to be
> copies/replicas of other tasks. When the first of the replicas finishes, we
> must kill the other ones.
>
> The master node has a code like this:
>
> TRY { MSG_task_cancel (task_list[i][tid]); } CATCH (e) {}
> MSG_task_destroy (task_list[i][tid]);
>
> And the worker host has something like this:
>
> TRY { MSG_task_execute (task); } CATCH (e) {}
>
> Maybe we are not using the try/catch block correctly? ... Is there any
> simgrid function that we can call inside the catch block, to avoid the
> memory usage? It doesn't seem to be a leak per se, since the memory is
> still reachable according to valgrind.
>
You need to free the exception when it happens. Use the xbt_ex_free
(xbt_ex_t e) function.

>
> As for your problem, did I mention that we managed to launch 2M nodes
>> by reducing the size of the system stack that each of them gets? Check
>> the contexts/stack_size command line configuration option.
>>
>
> I have no idea of what you are talking about, but it seems to be very
> interesting. We will take a look into that for sure! ;)
>
>
>> And to finally answer your question, the routing code were changed
>> recently (as in "this year", not sure which stable version anymore),
>> but it only leaded to much more memory efficient representations.
>>
>
> Ok, great. We already simulated large environments with simgrid, but our
> current work is different, and we are using some simgrid features for the
> first time, and that's why we didn't know what to expect.
>
> Thanks for your time!
>
> Cheers,
> Wagner
>
>
> _______________________________________________
> Simgrid-user mailing list
> Simgrid-user at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/simgrid-user
>



-- 
Bruno Donassolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/simgrid-user/attachments/20110721/2fbacc0b/attachment.htm>


More information about the Simgrid-user mailing list