its on OpenSuSE 11 with kernel 18.104.22.168. 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.
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:
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