https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122590
Bug ID: 122590
Summary: [OpenMP] Issue with allocator handling – when mixing
pinned memory with memkind/numa related features
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: documentation, openmp
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: grahams at gcc dot gnu.org, jakub at gcc dot gnu.org
Target Milestone: ---
This relates to
* the documentation at
https://gcc.gnu.org/onlinedocs/libgomp/Memory-allocation.html
* The implementation of omp_init_allocator
* Memory allocation
Namely, what happens if a NUMA or MEMKIND allocator is used – but also the
PINNED memory trait has been specified.
The current allocator code looks like:
if (memkind == GOMP_MEMKIND_LIBNUMA)
ptr = libnuma_data->numa_alloc_local (new_size);
else if (memkind)
…
ptr = memkind_data->memkind_malloc (kind, new_size);
else
…
ptr = MEMSPACE_ALLOC (memspace, new_size, pinned);
i.e. memkind/numa always wins. – This usually is fine, but especially
with pinned memory, it is probably better if pinned memory wins as this
might be detectable.
Additionally, the current wording in the documentation does not make clear
what happens.
NOTE: I think the allocation part above is actually fine; the issue is
rather in omp_init_allocator which for some memory spaces uses
memkind/numa – and still accepts the pinned trait.
IMHO, there are two solutions:
(A) Fail with omp_null_allocator in that case – or
(B) Accept pinned memory – but reset "data.memkind = GOMP_MEMKIND_NONE".
I think the latter would be okay. — Additionally, the documentation needs to be
updated to make clear what the implementation does in that case.
* * *
Ref: The issue probably exists since the initial pinned-memory support, i.e
r14-6499-g348874f0baac0f libgomp: basic pinned memory on Linux
Some wording change to the documentation, related to pinned memory, exacerbate
the documentation issue, but did not affect the actual algorithm and, hence,
the issue illustrated above. Thus, this is now an extra PR and wasn't fixed as
part of that/those commit(s). (They didn't even touch the libgomp/allocator.c
file. For completeness, I am talking about the commits r16-4574-g3b8d9d579c2931
and r16-4575-g9e5a9aa49051c3 )
