https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110663
Bug ID: 110663
Summary: [OpenMP] Use 'affinity' clause for node placement for
the 'task' construct
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization, openmp
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Follow up to PR99666.
We currently accept the affinity clause (since r12-1108-g9a5de4d5af1c10 with a
couple of follow-up commits) – however, after evaluation it is ignored.
HPC indicated that it would be useful it would actually be useful to place
threads on the node where the data is present.
libnuma (→ https://github.com/numactl/numactl ) defines a function
(get_mempolicy) which calls the Linux kernel (syscall) to determine on which
node a given pointer address is located (allocated or moved to).
This data can then be used to find the associated CPUs using the /sys data
(e.g. via libnuma, which caches that data).
(Note that get_mempolicy will only return the node for the address; the storage
might span multiple nodes, e.g. with allocation 'blocked'/'interleaved'.
The affinity clause knows about the size and not only about the first address.
(Cf also https://gcc.gnu.org/onlinedocs/libgomp/Memory-allocation.html )
* * *
>From the OpenMP spec:
"affinity Clause
"The affinity clause specifies a hint to indicate data affinity of tasks
generated by the construct on which it appears. The hint recommends to execute
generated tasks close to the location of the original list items. A program
that relies on the task execution location being determined by this list may
have unspecified behavior.
"The list items that appear in the affinity clause may also appear in
data-environment clauses. The list items may reference any iterators-identifier
that is defined in the same clause and may include array sections.
"[C/C++] The list items that appear in the affinity clause may use
shape-operators."
