Re: [PATCH] libgomp, openmp: pinned memory

On 10/02/2023 15:11, Thomas Schwinge wrote: Hi! Re OpenMP 'pinned' memory allocator trait semantics vs. 'omp_realloc': On 2022-01-13T13:53:03+, Andrew Stubbs wrote: On 05/01/2022 17:07, Andrew Stubbs wrote: [...], I'm working on an implementation using mmap instead of malloc for pinned a

Re: [PATCH] libgomp, openmp: pinned memory

Hi! Re OpenMP 'pinned' memory allocator trait semantics vs. 'omp_realloc': On 2022-01-13T13:53:03+, Andrew Stubbs wrote: > On 05/01/2022 17:07, Andrew Stubbs wrote: >> [...], I'm working on an implementation using mmap instead of malloc >> for pinned allocations. [...] > This means that la

RE: [PATCH] libgomp, openmp: pinned memory

> For example, it's documented that 'cuMemHostAlloc', > api/group__CUDA__MEM.html#group__CUDA__MEM_1g572ca4011bfcb25034888a14d4e035b > 9>, > "Allocates page-locked host memory". The crucial thing, though, what > makes this different from 'malloc' plus '

RE: [PATCH] libgomp, openmp: pinned memory

> The question is only what to do with 'requires unified_shared_memory' – > and a non-multi-device allocator. The compiler emits an error at compile time if you attempt to use both -foffload-memory=pinned and USM, because they’re not compatible. You're fine to use both explicit allocators in the

Re: [PATCH] libgomp, openmp: pinned memory

On 09.06.22 11:38, Thomas Schwinge wrote: On 2022-06-07T13:28:33+0100, Andrew Stubbs wrote: On 07/06/2022 13:10, Jakub Jelinek wrote: On Tue, Jun 07, 2022 at 12:05:40PM +0100, Andrew Stubbs wrote: The memory pinned via the mlock call does not give the expected performance boost. I had not exp

Re: [PATCH] libgomp, openmp: pinned memory

Hi! I'm not all too familiar with the "newish" CUDA Driver API, but maybe the following is useful still: On 2022-06-07T13:28:33+0100, Andrew Stubbs wrote: > On 07/06/2022 13:10, Jakub Jelinek wrote: >> On Tue, Jun 07, 2022 at 12:05:40PM +0100, Andrew Stubbs wrote: >>> Following some feedback fro

Re: [PATCH] libgomp, openmp: pinned memory

On Tue, Jun 07, 2022 at 01:28:33PM +0100, Andrew Stubbs wrote: > > For performance boost of what kind of code? > > I don't understand how Cuda API could be useful (or can be used at all) if > > offloading to NVPTX isn't involved. The fact that somebody asks for host > > memory allocation with omp_

Re: [PATCH] libgomp, openmp: pinned memory

On 07/06/2022 13:10, Jakub Jelinek wrote: On Tue, Jun 07, 2022 at 12:05:40PM +0100, Andrew Stubbs wrote: Following some feedback from users of the OG11 branch I think I need to withdraw this patch, for now. The memory pinned via the mlock call does not give the expected performance boost. I had

Re: [PATCH] libgomp, openmp: pinned memory

On Tue, Jun 07, 2022 at 12:05:40PM +0100, Andrew Stubbs wrote: > Following some feedback from users of the OG11 branch I think I need to > withdraw this patch, for now. > > The memory pinned via the mlock call does not give the expected performance > boost. I had not expected that it would do much

Re: [PATCH] libgomp, openmp: pinned memory

Following some feedback from users of the OG11 branch I think I need to withdraw this patch, for now. The memory pinned via the mlock call does not give the expected performance boost. I had not expected that it would do much in my test setup, given that the machine has a lot of RAM and my ben

Re: [PATCH] libgomp, openmp: pinned memory

On 05/01/2022 17:07, Andrew Stubbs wrote: I don't believe 64KB will be anything like enough for any real HPC application. Is it really worth optimizing for this case? Anyway, I'm working on an implementation using mmap instead of malloc for pinned allocations. I figure that will simplify the u

Re: [PATCH] libgomp, openmp: pinned memory

On 04/01/2022 18:47, Jakub Jelinek wrote: On Tue, Jan 04, 2022 at 07:28:29PM +0100, Jakub Jelinek via Gcc-patches wrote: Other issues in the patch are that it doesn't munlock on deallocation and that because of that deallocation we need to figure out what to do on page boundaries. As documented

Re: [PATCH] libgomp, openmp: pinned memory

On Tue, Jan 04, 2022 at 07:28:29PM +0100, Jakub Jelinek via Gcc-patches wrote: > > > Other issues in the patch are that it doesn't munlock on deallocation and > > > that because of that deallocation we need to figure out what to do on page > > > boundaries. As documented, mlock can be passed addre

Re: [PATCH] libgomp, openmp: pinned memory

On Tue, Jan 04, 2022 at 04:58:19PM +, Andrew Stubbs wrote: > > I think perror is the wrong thing to do, omp_alloc etc. has a well defined > > interface what to do in such cases - the allocation should just fail (not be > > allocated) and depending on user's choice that can be fatal, or return N

Re: [PATCH] libgomp, openmp: pinned memory

On 04/01/2022 15:55, Jakub Jelinek wrote: The usual libgomp way of doing this wouldn't be to use #ifdef __linux__, but instead add libgomp/config/linux/allocator.c that includes some headers, defines some macros and then includes the generic allocator.c. OK, good point, I can do that. I think

Re: [PATCH] libgomp, openmp: pinned memory

On Tue, Jan 04, 2022 at 03:32:17PM +, Andrew Stubbs wrote: > This patch implements the OpenMP pinned memory trait for Linux hosts. On > other hosts and on devices the trait becomes a no-op (instead of being > rejected). > > The memory is locked via the mlock syscall, which is both the "correct