[Bug libgomp/110663] New: [OpenMP] Use 'affinity' clause for node placement for the 'task' construct

[Bug libgomp/110663] New: [OpenMP] Use 'affinity' clause for node placement for the 'task' construct

[burnus at gcc dot gnu.org]

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."

[Bug libgomp/110663] [OpenMP] Use 'affinity' clause for node placement for the 'task' construct

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110663

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Carry on of Jakub's comment in PR99666 about implementing this:

"Yeah, but not really sure if we want to do anything with it other than accept
it / verify the restrictions.
"The tasking is already overly complicated and the right way is to make it more
scalable (have per thread task queues with work stealing rather than the 3
different queues we currently have with per-team lock)."

[Bug libgomp/110663] [OpenMP] Use 'affinity' clause for node placement for the 'task' construct

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110663

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #55541|0                           |1
        is obsolete|                            |

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 55566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55566&action=edit
Partial libgomp/task.c patch, showing how this could be implemented