[Openmp-commits] [PATCH] D141227: [OpenMP][libomptarget] Implement memory lock/unlock API in NextGen plugins

Carlo Bertolli via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Tue Jan 10 14:14:42 PST 2023

carlo.bertolli added a comment.

In D141227#4041529 <https://reviews.llvm.org/D141227#4041529>, @carlo.bertolli wrote:

> In D141227#4041177 <https://reviews.llvm.org/D141227#4041177>, @JonChesterfield wrote:
>> What is locked memory, and could we define it in a comment/documentation somewhere if it isn't already?
>> Is it the same as mmap LOCKED? That plus extra?
>> Does it imply GPUs can read/write it? If so, can they read/write within a kernel execution, or can we implement locked memory by copy at the start and end of the execution?

I forgot to answer this: a locked pointer is passed a set of agents that can access it. It is best described as a "agent accessible pointer". In the "first gen" plugin, we use the agent accessible pointer (via call to lock) to perform a memory_async_copy, passing in the GPU agent involved in the copy.

> Good question!
> I always refer back to this article for a definition of locked/pinned:
> https://lwn.net/Articles/600502/
> but it might be stale, as my knowledge of OS is.
> Aside from what I know or not know about OS, this is a kernel concept that we are reflecting in the plugin's.
> In general, it is a concept used CUDA and HSA, so perhaps we can refer back to it?
> We care about locking host memory because - roughly speaking - hsa_amd_memory_async_copy (asynchronous H2D and D2H memory copy) has a fast path for prelocked/pinned memory.
> As locking memory is expensive, putting some "space" between lock operations, memory copies, and unlock operations is an effective optimization strategy. That's why we are giving users an API to prelock pointers when they know they can, and we avoid relocking them in the plugin's.
> I hope this helps.



More information about the Openmp-commits mailing list