its on OpenSuSE 11 with kernel 2.6.25.11. I don't know the libnuma
library version, but I suspect that its fairly new.
I will try to investigate that in the next days a little more. I do
think that they use sched_setaffinity() underneath the hood (because in
one of my failed attempts when I passed in the wrong argument, I got
actually the same error message that I got earlier with
sched_setaffinity), but they must do something additionally underneath.
Anyway, I just wanted to report the result, and that there is obviously
a difference, even if can't explain it right now in details.
Thanks
Edgar
Jeff Squyres wrote:
On Dec 2, 2008, at 11:27 AM, Edgar Gabriel wrote:
so I ran a couple of tests today and I can not confirm your statement.
I wrote simple a simple test code where a process first sets an
affinity mask and than spawns a number of threads. The threads modify
the affinity mask and every thread ( including the master thread)
print out there affinity mask at the end.
With sched_getaffinity() and sched_setaffinity() it was indeed such
that the master thread had the same affinity mask as the thread that
it spawned. This means, that the modification of the affinity mask by
a new thread in fact did affect the master thread.
Executing the same codesquence however using the libnuma calls, the
master thread however was not affected by the new affinity mask of the
children. So clearly, libnuma must be doing something differently.
What distro/version of Linux are you using, and what version of libnuma?
Libnuma v2.0.x very definitely is just a wrapper around the syscall for
sched_setaffinity(). I downloaded it from:
ftp://oss.sgi.com/www/projects/libnuma/download
--
Edgar Gabriel
Assistant Professor
Parallel Software Technologies Lab http://pstl.cs.uh.edu
Department of Computer Science University of Houston
Philip G. Hoffman Hall, Room 524 Houston, TX-77204, USA
Tel: +1 (713) 743-3857 Fax: +1 (713) 743-3335