Hi! On 2023-02-20T09:48:53+0000, Andrew Stubbs wrote: > On 17/02/2023 08:12, Thomas Schwinge wrote: >> On 2023-02-16T23:06:44+0100, I wrote: >>> On 2023-02-16T16:17:32+0000, "Stubbs, Andrew via Gcc-patches" wrote: >>>> The mmap implementation was not optimized for a lot of small allocations, and I can't see that issue changing here >>> >>> That's correct, 'mmap' remains. Under the hood, 'cuMemHostRegister' must >>> surely also be doing some 'mlock'-like thing, so I figured it's best to >>> feed page-boundary memory regions to it, which 'mmap' gets us. >>> >>>> so I don't know if this can be used for mlockall replacement. >>>> >>>> I had assumed that using the Cuda allocator would fix that limitation. >>> >>> From what I've read (but no first-hand experiments), there's non-trivial >>> overhead with 'cuMemHostRegister' (just like with 'mlock'), so routing >>> all small allocations individually through it probably isn't a good idea >>> either. Therefore, I suppose, we'll indeed want to use some local >>> allocator if we wish this "optimized for a lot of small allocations". >> >> Eh, I suppose your point indirectly was that instead of 'mmap' plus >> 'cuMemHostRegister' we ought to use 'cuMemAllocHost'/'cuMemHostAlloc', as >> we assume those already do implement such a local allocator. Let me >> quickly change that indeed -- we don't currently have a need to use >> 'cuMemHostRegister' instead of 'cuMemAllocHost'/'cuMemHostAlloc'. > > Yes, that's right. I suppose it makes sense to register memory we > already have, but if we want new memory then trying to reinvent what > happens inside cuMemAllocHost is pointless. I've pushed to devel/omp/gcc-12 branch commit 4bd844f3e0202b3d083f0784f4343570c88bb86c "Attempt to not just register but allocate OpenMP pinned memory using a device", 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