#2712: Parallel GC scheduling problems
-----------------------------------------+----------------------------------
Reporter: simonmar | Owner: simonmar
Type: run-time performance bug | Status: closed
Priority: high | Milestone: 6.12 branch
Component: Runtime System | Version: 6.11
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Moderate (1 day)
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-----------------------------------------+----------------------------------
Changes (by simonmar):
* status: new => closed
* version: 6.10.1 => 6.11
* resolution: => fixed
* milestone: 6.10.2 => 6.12 branch
Comment:
Done in the HEAD, but I probably won't backport because the changes are
too large and potentially destabilising. Here's the main patch, for
reference:
{{{
Fri Nov 21 15:12:33 GMT 2008 Simon Marlow <[EMAIL PROTECTED]>
* Use mutator threads to do GC, instead of having a separate pool of GC
threa
ds
Previously, the GC had its own pool of threads to use as workers when
doing parallel GC. There was a "leader", which was the mutator thread
that initiated the GC, and the other threads were taken from the pool.
This was simple and worked fine for sequential programs, where we did
most of the benchmarking for the parallel GC, but falls down for
parallel programs. When we have N mutator threads and N cores, at GC
time we would have to stop N-1 mutator threads and start up N-1 GC
threads, and hope that the OS schedules them all onto separate cores.
It practice it doesn't, as you might expect.
Now we use the mutator threads to do GC. This works quite nicely,
particularly for parallel programs, where each mutator thread scans
its own spark pool, which is probably in its cache anyway.
There are some flag changes:
-g<n> is removed (-g1 is still accepted for backwards compat).
There's no way to have a different number of GC threads than mutator
threads now.
-q1 Use one OS thread for GC (turns off parallel GC)
-qg<n> Use parallel GC for generations >= <n> (default: 1)
Using parallel GC only for generations >=1 works well for sequential
programs. Compiling an ordinary sequential program with -threaded and
running it with -N2 or more should help if you do a lot of GC. I've
found that adding -qg0 (do parallel GC for generation 0 too) speeds up
some parallel programs, but slows down some sequential programs.
Being conservative, I left the threshold at 1.
ToDo: document the new options.
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2712#comment:1>
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
