From: Alexander Monakov <amonakov@ispras.ru>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Cesar Philippidis <cesar@codesourcery.com>,
Thomas Schwinge <thomas@codesourcery.com>,
Martin Jambor <mjambor@suse.cz>,
gcc-patches@gcc.gnu.org
Subject: Re: [RFC PATCH] Coalesce host to device transfers in libgomp
Date: Tue, 24 Oct 2017 17:56:00 -0000 [thread overview]
Message-ID: <alpine.LNX.2.20.13.1710242039360.23720@monopod.intra.ispras.ru> (raw)
In-Reply-To: <20171024155926.GN14653@tucnak>
On Tue, 24 Oct 2017, Jakub Jelinek wrote:
> > Why did you chose the 32KB and 4KB limits? I wonder if that would have
> > any impact on firstprivate_int values. If this proves to be effective,
> > it seems like we should be able to eliminate GOMP_MAP_FIRSTPRIVATE_INT
> > altogether.
>
> The thing is that this is a generic code, so it is hard to come up with
> reasonable limits. We could even have some limits e.g. in *devicep
> if we get different needs for different offloading targets.
>
> The 32KB and 4KB just come from some discussions with Alexander on IRC
> that larger copies saturate the PCI and the overhead isn't significant, so
> in that case copying e.g. megabyte into another memory and then to the
> device would likely not be beneficial.
Hm, I guess some miscommunication happened here. On IRC I said,
>> from my tests, at 32+MB it approaches bus bandwidth (10GB/s for gen3 pcie),
>> at few kilobytes I'd expect aggregation to pay off
Note I really meant 32+ megabytes, not kilobytes, but of course I'm not
suggesting that libgomp allocates a multi-megabyte staging buffer and
memcpy's everything into it all the time.
Generally speaking, for optimal transfers one should use permanently allocated
locked ("pinned") memory and/or asynchronous transfers, but unfortunately at the
moment I don't have a good understanding of existing design and OpenMP spec
constraints to know what libgomp can/should do.
Alexander
next prev parent reply other threads:[~2017-10-24 17:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 9:57 Jakub Jelinek
2017-10-24 15:59 ` Cesar Philippidis
2017-10-24 16:02 ` Jakub Jelinek
2017-10-24 17:56 ` Alexander Monakov [this message]
2017-10-24 17:40 ` Alexander Monakov
2017-10-24 19:36 ` Jakub Jelinek
2017-10-25 12:03 ` Jakub Jelinek
2017-10-27 14:13 ` [PATCH] Implement omp async support for nvptx Tom de Vries
2017-10-30 7:25 ` Jakub Jelinek
2017-10-30 12:02 ` Tom de Vries
2017-10-30 13:52 ` Tom de Vries
2018-12-06 17:02 ` [RFC PATCH] Coalesce host to device transfers in libgomp Thomas Schwinge
2018-12-06 17:19 ` Jakub Jelinek
2018-12-06 17:54 ` Thomas Schwinge
2018-12-06 17:57 ` Jakub Jelinek
2018-12-09 12:53 ` Thomas Schwinge
2019-12-18 17:15 ` Thomas Schwinge
2019-05-23 14:40 ` Thomas Schwinge
2019-05-23 14:57 ` Jakub Jelinek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.20.13.1710242039360.23720@monopod.intra.ispras.ru \
--to=amonakov@ispras.ru \
--cc=cesar@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=mjambor@suse.cz \
--cc=thomas@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).