Manuel M T Chakravarty wrote:
I am fixing that for Mac OS right now.
The comment above setThreadAffinity() says,
// Schedules the thread to run on CPU n of m. m may be less than the
// number of physical CPUs, in which case, the thread will be allowed
// to run on CPU n, n+m, n+2m etc.
I am not convinced that this is a good plan. If m is less than n, some
threads can hop between CPUs and so invalidate their L2 cache
repeatedly. The man page for sched_setaffinity() says,
Restricting a process to run on a single CPU also prevents the
performance cost caused by the cache invalidation that occurs when a
process ceases to execute on one CPU and then recommences execution on
a different CPU.
Besides, you call this function with
setThreadAffinity(cap->no, n_capabilities);
So, m is the number of capabilities, not the number of CPUs. The way I
understand the man page of sched_setaffinity(), if I run a Haskell
program with +RTS -N4 on an 8 core machine, it can only ever use the
first four cores of the system when thread affinity is used.
The idea is that when you use +RTS -N4 on an 8 core machine, the first
capability is allowed to run on CPUS 1 and 5, the second on 2 and 6, and so
on. It just ensures that threads on different Capabilities don't pre-empt
each other.
Well, maybe we also want to be able to say "just use CPUS 1-4" for locality
reasons, as you say. But why 1-4, and not 4-8? It doesn't make much sense
to pick particular CPUs, hence the current method.
This stuff is just for benchmarking and playing around with - I don't think
fixing affinity like this is a good idea in general.
The above specification of setThreadAddinity() is also rather specific
to the Linux API. On OS X, the idea is not to nail a given thread to a
fixed CPU, but to express constraints for the scheduling of a set of
threads (eg, requiring that all threads should run on different cores
without fixing the identity of the cores on which they run). This is
much more what you really want on a multi-user system. Hence, I suggest
to change the specification of setThreadAffinity().
That sounds much better. As I said, this is just experimental right now.
Cheers,
Simon
Manuel
Manuel M T Chakravarty:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -optc-Werror
-optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-Ieventlog
-optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild
-optc-I../libffi/build/include -optc-fno-strict-aliasing -Werror
-H64m -O0 -fasm -optc-O2 -I../includes -I. -Iparallel -Ism -Ieventlog
-DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild
-I../libffi/build/include -I. -dcmm-lint -hisuf thr_hi -hcsuf thr_hc
-osuf thr_o -optc-DTHREADED_RTS -c posix/OSThreads.c -o
posix/OSThreads.thr_o
posix/OSThreads.c: In function 'setThreadAffinity':
posix/OSThreads.c:213:0: warning: unused parameter 'n'
posix/OSThreads.c:213:0: warning: unused parameter 'm'
Do you guys need a box to run validate runs on OS X? I can offer one.
Manuel
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
