[GHC] #3553: parallel gc suffers badly if one thread is descheduled

[GHC]

#3553: parallel gc suffers badly if one thread is descheduled
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  igloo       
        Type:  merge             |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.2      
   Component:  Runtime System    |      Version:  6.10.4      
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => igloo
  * failure:  => None/Unknown
  * type:  bug => merge


Comment:

 This patch helps a lot:

 {{{
 Fri Jan 22 16:49:11 GMT 2010  Simon Marlow <marlowsd at gmail.com>
   * When acquiring a spinlock, yieldThread() every 1000 spins (#3553,
 #3758)

   This helps when the thread holding the lock has been descheduled,
   which is the main cause of the "last-core slowdown" problem.  With
   this patch, I get much better results with -N8 on an 8-core box,
   although some benchmarks are still worse than with 7 cores.

   I also added a yieldThread() into the any_work() loop of the parallel
   GC when it has no work to do. Oddly, this seems to improve performance
   on the parallel GC benchmarks even when all the cores are busy.
   Perhaps it is due to reducing contention on the memory bus.
 }}}

 See [http://ghcmutterings.wordpress.com/2010/01/25/yielding-more-
 improvements-in-parallel-performance/ this blog post] for more info.

 I'm going to close the bug, since I think this is the best we can do until
 we implement on-the-fly minor GCs.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3553#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler