------- Comment #4 from jv244 at cam dot ac dot uk 2010-07-06 10:01 ------- (In reply to comment #3) > That's how GOMP_CPU_AFFINITY works - it is a round-robin assignment of CPUs > upon thread creation, and the first two threads are never recreated in this > case. > Currently there is no tracking on how many threads bind to which CPU etc. > We'd need to track that in some data structure and choose CPU with lowest > number of assigned threads or something.
oops... this really is a surprise, is there a way that these 6 threads are not destroyed entering the parallel region that asks for 2 threads. That should fix the problem. Other compilers do the expected thing, for example intel: ifort -openmp test.f90 get_affinity.o export OMP_NUM_THREADS=8 export KMP_AFFINITY="proclist=[0,1,2,3,4,5,6,7]" > ./a.out OMP: Warning #63: KMP_AFFINITY: proclist specified, setting affinity type to "explicit". Entering first parallel region all threads bindings are 0 1 2 3 4 5 6 7 Entering second parallel region using two threads bindings are 0 1 Entering third parallel region using all threads bindings are 0 1 2 3 4 5 6 7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
