Re: [Starpu-devel] Assert : Number of copy requests left is not zero

[Samuel Thibault <samuel.thibault@ens-lyon.org>]

Hello,

Xavier Lacoste, le Tue 04 Nov 2014 10:05:38 +0100, a écrit :
> So the flushing at soon as possible versus flush all seems to be very 
> efficient (I don't think an other of my modifications could lead to this 
> performance improvement).
> Cases which didn't succeed due to memory consumption succeeded now.

Maybe these two go together.  As I wrote earlier, flush_all should be
doing just the same.  There are actually two parts:

- Cache management: this is an overhead at submission time. flushing as
soon as possible avoids making the cache keeping growing during task
submission.  This may be a source of overhead in your case since I guess
you have a lot of data.  Did you measure the time to actually submit the
tasks (i.e. between just before the first task_insert and just before
the task_wait_for_all)?

- Data deallocation: in both cases, the same is done: submitting the
invalidation of the data, which gets inserted in the same place in
the DAG, unless some task accesses the data between where you put the
explicit flush and where you put the flush_all.  So it should be just
the same.

> [starpu][_starpu_mpi_early_data_check_termination][assert failure] Number 
> of copy requests left is not zero
> 
> dsimple: ../../../mpi/src/starpu_mpi_early_data.c:45: 
> _starpu_mpi_early_data_check_termination: Assertion 
> `_starpu_mpi_early_data_handle_hashmap_count == 0' failed.
> 
> Have you get an idea of what could cause this assert ?

I have added a note in the message: did you forget to post a receive
corresponding to a send?

> Or a deadlock can also happen (deadlock marked on the result picture), I 
> don't know if this can be linked.

Possibly the converse: a receive which is missing a send.

Samuel