Re: [RFC PATCH] Coalesce host to device transfers in libgomp

[Jakub Jelinek <jakub@redhat.com>]

On Thu, May 23, 2019 at 04:40:14PM +0200, Thomas Schwinge wrote:
> Hi!
> 
> On Tue, 24 Oct 2017 11:55:27 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> > The following patch implements coalescing of transfers (only those that are
> > copied into the freshly allocated device buffer) into one or multiple larger
> > transfers.  The patch doesn't coalesce > 32KB transfers or transfers where
> > the gap is 4KB or more.  I guess it would be not too hard to do similar
> > coalescing for the dev2host transfers that are from a single device mapping,
> > though probably far less important than the more common host2dev transfers.
> 
> I too wondered about device to host copies.  (..., and in the OpenACC
> context, how that would interact with 'async'...)
> 
> And then, I wondered about 'OpenMP target enter data' directives -- if
> that one creates/copies multiple objects, wouldn't that likewise benefit
> from the coalescing optimization?  There is the (implementation?)
> problem, though, that 'GOMP_target_enter_exit_data' calls 'gomp_map_vars'
> separately for each mapping -- is that just because of the special
> 'GOMP_MAP_STRUCT' handling?  (Could we easily do "ranges" between such
> interrupters?)

No, the reason for that is that while for target data and target we can
estimate the lifetime of the device data (sure, one can do weird things
too), with enter data / exit data it is far less likely that the data that
will be mapped by the same enter data will be deallocated by an exit data
together as well.  If one allocates all data together on enter data and then
frees all but one of them, the whole block will need to be allocated on the
device until even the last one is freed.
For target construct, the only way to get something similar would be if some
other thread performs target enter data while the target task is running,
that would be quite racy.  For target data, one can add target enter data
inside of target data, but it is quite unusual I'd say.

	Jakub