[Bug libgomp/114765] linking to libgomp and setting CPU_PROC_BIND causes affinity reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113698 Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #7 from Andrew Pinski --- Invalid as explained. Also see PR 113698 .
[Bug libgomp/114765] linking to libgomp and setting CPU_PROC_BIND causes affinity reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765 --- Comment #6 from Jakub Jelinek --- (In reply to Alexander Monakov from comment #5) > Can libgomp defer changing affinity of the initial thread to the launch of > the first parallel region (i.e. change it only at thread pool > initialization, together with new threads)? The creation of a parallel region is very performance sensitive area, so slowing it down is undesirable. But more importantly, if the initial thread switches binding only at that point, it will mean memory allocated by the initial thread might no longer be close to that thread.
[Bug libgomp/114765] linking to libgomp and setting CPU_PROC_BIND causes affinity reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #5 from Alexander Monakov --- Can libgomp defer changing affinity of the initial thread to the launch of the first parallel region (i.e. change it only at thread pool initialization, together with new threads)?
[Bug libgomp/114765] linking to libgomp and setting CPU_PROC_BIND causes affinity reset
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765 --- Comment #3 from Jakub Jelinek --- (In reply to Stijn De Weirdt from comment #2) > 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). libgomp has library constructors which already do 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. See the OpenMP standard. By using that env variable (or similar), you request that the initial thread binds to a certain CPU/thread (the OMP_PROC_BIND=true case is less specified than when using say OMP_PLACES and exact rules which thread binds to which place).
[Bug libgomp/114765] linking to libgomp and setting CPU_PROC_BIND causes affinity reset
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] linking to libgomp and setting CPU_PROC_BIND causes affinity reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765 --- Comment #1 from Jakub Jelinek --- That is how it should behave. Don't use OMP_PROC_BIND=true unless that is what you want...
