GHC Threads affinity

Michael Baikov manpacket at
Sun Sep 10 03:03:10 UTC 2017


Currently GHC supports two kinds of threads - pinned to a specific
capability (bound threads) and those it can migrate between any
capabilities (unbound threads). For purposes of achieving lower latency in
Haskell applications it would be nice to have something in between -
threads GHC can migrate but within a certain subset of capabilities only.

I'm developing a program that contains several kinds of threads - those
that do little work and sensitive to latency and those that can spend more
CPU time and less latency sensitive. I looked into several cases of
increased latency in those sensitive threads (using GHC eventlog) and in
all cases sensitive threads were waiting for non-sensitive threads to
finish working. I was able to reduce worst case latency by factor of 10 by
pinning all the threads in the program to specific capability but manually
distributing threads (60+ of them) between capabilities (several different
machines with different numbers of cores available) seems very fragile.
World stopping GC is still a problem but at least in my case is much less
frequently so.

It would be nice to be able to allow GHC runtime to migrate a thread
between a subset of capabilities using interface similar to this one:

-- creates a thread that is allowed to migrate between capabilities
according to following rule: ghc is allowed to run this thread on Nth
capability if Nth `mod` size_of_word bit in mask is set.
forkOn' :: Int -> IO () -> IO ThreadId
forkOn' mask act = undefined

This should allow to define up to 64 (32) distinct groups and allow user to
break down their threads into bigger number of potentially intersecting
groups by specifying things like capability 0 does latency sensitive
things, caps 1..5 - less  sensitive things, caps 6-7 bulk things.

Anything obvious I'm missing? Any recommendations to how to implement this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list