[og12] libgomp: Document OpenMP 'pinned' memory (was: [PATCH] libgomp, openmp: pinned memory)

Message ID 878rfiqvtn.fsf@euler.schwinge.homeip.net
State Deferred
Headers
Series [og12] libgomp: Document OpenMP 'pinned' memory (was: [PATCH] libgomp, openmp: pinned memory) |

Commit Message

Thomas Schwinge March 27, 2023, 11:26 a.m. UTC
  Hi!

On 2023-03-27T09:27:31+0000, "Stubbs, Andrew" <andrew.stubbs@siemens.com> wrote:
>> -----Original Message-----
>> From: Thomas Schwinge <thomas@codesourcery.com>
>> Sent: 24 March 2023 15:50
>>
>> On 2022-01-04T15:32:17+0000, Andrew Stubbs <ams@codesourcery.com>
>> wrote:
>> > This patch implements the OpenMP pinned memory trait [...]
>>
>> I figure it may be helpful to document the current og12 state of affairs; does
>> the attached "libgomp: Document OpenMP 'pinned' memory" look good to
>> you?
>
> I don't really know what "allocated via the device" means?

Heh, you're right.

> I mean, I presume you mean "via CUDA", but I don't think this is obvious to the average reader.
> Maybe "allocation is optimized for the device" or some such thing?

As we're in sections that are documenting GCN vs. nvptx specifics, we
might indeed call out which exact interfaces we're using.

How's the updated "libgomp: Document OpenMP 'pinned' memory", see
attached?


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
  

Comments

Andrew Stubbs March 27, 2023, 12:01 p.m. UTC | #1
On 27/03/2023 12:26, Thomas Schwinge wrote:
> Hi!
> 
> On 2023-03-27T09:27:31+0000, "Stubbs, Andrew" <andrew.stubbs@siemens.com> wrote:
>>> -----Original Message-----
>>> From: Thomas Schwinge <thomas@codesourcery.com>
>>> Sent: 24 March 2023 15:50
>>>
>>> On 2022-01-04T15:32:17+0000, Andrew Stubbs <ams@codesourcery.com>
>>> wrote:
>>>> This patch implements the OpenMP pinned memory trait [...]
>>>
>>> I figure it may be helpful to document the current og12 state of affairs; does
>>> the attached "libgomp: Document OpenMP 'pinned' memory" look good to
>>> you?
>>
>> I don't really know what "allocated via the device" means?
> 
> Heh, you're right.
> 
>> I mean, I presume you mean "via CUDA", but I don't think this is obvious to the average reader.
>> Maybe "allocation is optimized for the device" or some such thing?
> 
> As we're in sections that are documenting GCN vs. nvptx specifics, we
> might indeed call out which exact interfaces we're using.
> 
> How's the updated "libgomp: Document OpenMP 'pinned' memory", see
> attached?

LGTM, FWIW.

Andrew
  

Patch

From 03e09ad4e0b4cd2232e8bb036dd2562b18ea2686 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Fri, 24 Mar 2023 15:14:57 +0100
Subject: [PATCH] libgomp: Document OpenMP 'pinned' memory

	libgomp/
	* libgomp.texi (AMD Radeon, nvptx): Document OpenMP 'pinned'
	memory.
---
 libgomp/libgomp.texi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 288e0b3a8ea..6355ce2a37b 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -4456,6 +4456,9 @@  The implementation remark:
 @item OpenMP code that has a requires directive with @code{unified_address} or
       @code{unified_shared_memory} will remove any GCN device from the list of
       available devices (``host fallback'').
+@item OpenMP @emph{pinned} memory (@code{omp_atk_pinned},
+      @code{ompx_pinned_mem_alloc}, for example)
+      is allocated via @code{mmap}, @code{mlock}.
 @end itemize
 
 
@@ -4518,6 +4521,11 @@  The implementation remark:
 @item OpenMP code that has a requires directive with @code{unified_address}
       or @code{unified_shared_memory} will remove any nvptx device from the
       list of available devices (``host fallback'').
+@item OpenMP @emph{pinned} memory (@code{omp_atk_pinned},
+      @code{ompx_pinned_mem_alloc}, for example)
+      is allocated via @code{cuMemHostAlloc} (CUDA Driver API).
+      This potentially helps optimization of host <-> device data
+      transfers.
 @end itemize
 
 
-- 
2.25.1