#3758: Huge regression in concurrent app performance and reliability under
threaded runtime
-----------------------------+----------------------------------------------
Reporter: bos | Owner: simonmar
Type: bug | Status: new
Priority: high | Milestone: 6.12.2
Component: Runtime System | Version: 6.12.1
Resolution: | Keywords:
Difficulty: | Os: Linux
Testcase: | Architecture: x86_64 (amd64)
Failure: Runtime crash |
-----------------------------+----------------------------------------------
Changes (by simonmar):
* cc: [email protected] (added)
Comment:
Some more on this:
I'm still unable to reproduce any deadlocks, with either 6.12.1 or HEAD.
It's not unheard of for there to be bugs in Linux threading, but I haven't
seen any for a few years, and we're both running the same kernel (2.6.31).
So it could be a race that is tickled on your hardware but not mine, I'll
try on different hardware when I'm back in the office.
I've cobbled together a patch that should make the parallel GC better
behaved when only some of the cores are active: basically it doesn't
bother waking up idle cores to do a parallel GC. This avoids most of the
slowdown with -N2 here. I need to check that it doesn't hurt any of my
other benchmarks before committing.
Something else that helps a bit: `+RTS -qa` uses the Linux affinity API to
fix threads to CPUs.
I've noticed that if I go over 100 threads with `ab`, then a very few
requests take >3s, but the rest are under 100ms. That is suspicious, and
could indicate something strange in the scheduler.
You can also win by doing this:
{{{
forM_ [0..numCapabilities-1] $ \n ->
forkOnIO n (listenLoop sock)
}}}
and then run with `+RTS -N2 -qm -qa`, to disable automatic migration and
enable affinity. This basically assigns one server thread and its
children to each core, and doesn't let them move around.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3758#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
