[Bug libgomp/114765] linking to libgomp and setting CPU_PROC_BIND causes affinity reset

[stijn.deweirdt at ugent dot be via Gcc-bugs]

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

--- Comment #4 from Stijn De Weirdt  ---
hi jakub,


thanks for the explanation. so if i understand this, the main thread/process of
any binary linked with libgomp becomes an OpenMP thread, because of the libgomp
constructor doing something. and thus the OMP_PROC_BIND works as intended.

and what happens with other threads created in the code in such a case? these
are not openmp threads? or those are openmp threads, but related to the
"nesting"/"active levels"?

and can we "delay" the OMP_PROC_BIND safely (eg start the binary without
OMP_PROC_BIND, and "enable" it in the main; i am more thinking in python code
here: so after the import, we set the enviroment with OMP_PROC_BIND=true). will
this cause pinning for openmp threads started afterwards?

anyway, apologies again for my confusion and lack of detailed understanding. i
still find it a bit unexpected ;)

stijn

[Bug libgomp/114765] linking to libgomp and setting CPU_PROC_BIND causes affinity reset

[stijn.deweirdt at ugent dot be via Gcc-bugs]

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

--- Comment #2 from Stijn De Weirdt  ---
hi jakub,

apologies for my ignorance, but how is working as expected? i can't make this
up from the description of the variable; and it's unexpected since there is no
openmp code being run (naively then; clearly libgomp does something).

we have an environment where we set OMP_PROC_BIND=true because openmp code
clearly benefits from it; but it also affects code where libgomp is simply
linked to it, but nothing else is done with it.

if i would understand why or what libgomp does, i might be able to find some
workaround.

many thanks,

stijn

[Bug libgomp/114765] New: linking to libgomp and setting CPU_PROC_BIND causes affinity reset

[stijn.deweirdt at ugent dot be via Gcc-bugs]

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

Bug ID: 114765
   Summary: linking to libgomp and setting CPU_PROC_BIND causes
affinity reset
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stijn.deweirdt at ugent dot be
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Compiling c code that has no openmp statements, and linking libgomp to it;
running that binary with OMP_PROC_BIND=true causes affinity "reset" to single
core. In output below see differene between "100" and "11" in reported
affinity.

(This may sound odd, but the real origin of this issue comes from some python
code that does an 'import torch' and then all proceeding multiprocessing code
was pinned to single core; (and in an environment where OMP_PROC_BIND was set
to true). in the case of torch, it was the init importing something inked to
openblas which in turn was linked to libgomp)


Code below print affinity (named ompissue.c below)

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

void print_affinity() {
cpu_set_t mask;
long nproc, i;

if (sched_getaffinity(0, sizeof(cpu_set_t), ) == -1) {
perror("sched_getaffinity");
assert(false);
}
nproc = sysconf(_SC_NPROCESSORS_ONLN);
printf("sched_getaffinity = ");
for (i = 0; i < nproc; i++) {
printf("%d ", CPU_ISSET(i, ));
}
printf("\n");
}

int main(void) {
cpu_set_t mask;

print_affinity();
}


compile and link with "gcc -l gomp ompissue.c"

and then it run:

[stdweird@w011h183 tmp]$ OMP_DISPLAY_ENV=true OMP_PROC_BIND=TRUE ./with_omp 

OPENMP DISPLAY ENVIRONMENT BEGIN
  _OPENMP = '201511'
  [host] OMP_DYNAMIC = 'FALSE'
  [host] OMP_NESTED = 'FALSE'
  [host] OMP_NUM_THREADS = '1'
  [host] OMP_SCHEDULE = 'DYNAMIC'
  [host] OMP_PROC_BIND = 'TRUE'
  [host] OMP_PLACES = '{0},{4},{1},{5},{2},{6},{3},{7}'
  [host] OMP_STACKSIZE = '0'
  [host] OMP_WAIT_POLICY = 'PASSIVE'
  [host] OMP_THREAD_LIMIT = '4294967295'
  [host] OMP_MAX_ACTIVE_LEVELS = '1'
  [host] OMP_NUM_TEAMS = '0'
  [host] OMP_TEAMS_THREAD_LIMIT = '0'
  [all] OMP_CANCELLATION = 'FALSE'
  [all] OMP_DEFAULT_DEVICE = '0'
  [all] OMP_MAX_TASK_PRIORITY = '0'
  [all] OMP_DISPLAY_AFFINITY = 'FALSE'
  [host] OMP_AFFINITY_FORMAT = 'level %L thread %i affinity %A'
  [host] OMP_ALLOCATOR = 'omp_default_mem_alloc'
  [all] OMP_TARGET_OFFLOAD = 'DEFAULT'
OPENMP DISPLAY ENVIRONMENT END
sched_getaffinity = 1 0 0 0 0 0 0 0 
[stdweird@w011h183 tmp]$ OMP_DISPLAY_ENV=true OMP_PROC_BIND=FALSE ./with_omp 

OPENMP DISPLAY ENVIRONMENT BEGIN
  _OPENMP = '201511'
  [host] OMP_DYNAMIC = 'FALSE'
  [host] OMP_NESTED = 'FALSE'
  [host] OMP_NUM_THREADS = '1'
  [host] OMP_SCHEDULE = 'DYNAMIC'
  [host] OMP_PROC_BIND = 'FALSE'
  [host] OMP_PLACES = ''
  [host] OMP_STACKSIZE = '0'
  [host] OMP_WAIT_POLICY = 'PASSIVE'
  [host] OMP_THREAD_LIMIT = '4294967295'
  [host] OMP_MAX_ACTIVE_LEVELS = '1'
  [host] OMP_NUM_TEAMS = '0'
  [host] OMP_TEAMS_THREAD_LIMIT = '0'
  [all] OMP_CANCELLATION = 'FALSE'
  [all] OMP_DEFAULT_DEVICE = '0'
  [all] OMP_MAX_TASK_PRIORITY = '0'
  [all] OMP_DISPLAY_AFFINITY = 'FALSE'
  [host] OMP_AFFINITY_FORMAT = 'level %L thread %i affinity %A'
  [host] OMP_ALLOCATOR = 'omp_default_mem_alloc'
  [all] OMP_TARGET_OFFLOAD = 'DEFAULT'
OPENMP DISPLAY ENVIRONMENT END
sched_getaffinity = 1 1 1 1 1 1 1 1