From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74414 invoked by alias); 23 May 2019 14:40:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 74406 invoked by uid 89); 23 May 2019 14:40:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=device X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 May 2019 14:40:46 +0000 Received: from svr-orw-mbx-06.mgc.mentorg.com ([147.34.90.206]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1hTota-0003OG-SY from Thomas_Schwinge@mentor.com ; Thu, 23 May 2019 07:40:38 -0700 Received: from svr-orw-mbx-01.mgc.mentorg.com (147.34.90.201) by SVR-ORW-MBX-06.mgc.mentorg.com (147.34.90.206) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 23 May 2019 07:40:36 -0700 Received: from tftp-cs (147.34.91.1) by svr-orw-mbx-01.mgc.mentorg.com (147.34.90.201) with Microsoft SMTP Server id 15.0.1320.4 via Frontend Transport; Thu, 23 May 2019 07:40:36 -0700 Received: by tftp-cs (Postfix, from userid 49978) id 0E8DCC231E; Thu, 23 May 2019 07:40:36 -0700 (PDT) From: Thomas Schwinge To: Jakub Jelinek CC: , Alexander Monakov Subject: Re: [RFC PATCH] Coalesce host to device transfers in libgomp In-Reply-To: <20171024095527.GJ14653@tucnak> References: <20171024095527.GJ14653@tucnak> User-Agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/26.1 (x86_64-pc-linux-gnu) Date: Thu, 23 May 2019 14:40:00 -0000 Message-ID: <87ef4p2q0h.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-SW-Source: 2019-05/txt/msg01607.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 1527 Hi! On Tue, 24 Oct 2017 11:55:27 +0200, Jakub Jelinek wrote: > The following patch implements coalescing of transfers (only those that a= re > copied into the freshly allocated device buffer) into one or multiple lar= ger > 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 mappi= ng, > though probably far less important than the more common host2dev transfer= s. 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?) And then, could we go as far as using the coalescing optimization even for 'update'/'exit data' directives, and/or potentially for generally all host to device and device to host copies, when we can determine that the device addresses are adjacent to each other? Or would figuring that out require more effort compared to just launching individual transfers? Just an idea that I had... Gr=C3=BC=C3=9Fe Thomas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" Content-length: 658 -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEU9WEfWKGQazCmycCAKI7+41Q4XkFAlzmsNAACgkQAKI7+41Q 4XmcHAwAwiDiAbHDWwx5z9y7go8eWf2LEDo+JuxHAV+8CpYISatmPQRrspF0Kxuz iDGXTHYCAioPs39D2rRxDTnOE7+7dH1jFIfOZJ5JIfoowl+u1WB5jmK2QZGr0EnL pAAf//tNqc8rAfZlLjz6PQb2ADHNaU41EpuGcXVTglIy+Ock1A2lpSHB0EvdeSuU THPtx0XqGNhtbD3C+ciiNNsoLaC3XifYNp0nc4ElhLZhw5JyW6EdY82+3z4vRC98 HPk7MU73pnRHzpp5WGBARopJn/i55CJmGPGwSCIsywQRuMXHUTr8p6h7Yw3UIwI9 PI330EOYBjDE22jcS97HkqJJYQrsD5xhiBGGtqjX6GZuRBePOIOJJwtaZ66ujzSw biIm9Lg1878qdaPof41GcBJnVE1gqe45jfKpEU6Yn77Gqa5FFivQWXhUQhu0hxVl OK2X2EKn9R/Kd3YO8LQx51SgIJjAXap79E7oij8zf0PJTJCd3D7RQYNs9ZNN+L5A edB+h68Q =zVrv -----END PGP SIGNATURE----- --=-=-=--