[GHC] #7606: Stride scheduling for Haskell threads with priorities

[GHC]

#7606: Stride scheduling for Haskell threads with priorities
---------------------------------+------------------------------------------
    Reporter:  ezyang            |       Owner:  ezyang          
        Type:  feature request   |      Status:  new             
    Priority:  normal            |   Milestone:  7.8.1           
   Component:  Runtime System    |     Version:  7.7             
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------

Comment(by ezyang):

 OK, I have a much better sense for where the performance problems are
 coming from.

 ----

 Adding extra words to the TSO has no impact on most smp benchmarks, but
 really kills threads006 (up to 100% slowdown); this is not too surprising
 since this benchmark involves creating 200,000 threads. A representative
 stat without a small TSO is

 {{{
 224198416 bytes, 425 GCs (416 + 9), 0/0 avg/max bytes residency (0
 samples), 699092656 bytes GC work, 279M in use, 0.00 INIT (0.00 elapsed),
 0.02 MUT (0.02 elapsed), 0.33 GC (0.33 elapsed), 0.12 GC(0) (0.12
 elapsed), 0.21 GC(1) (0.21 elapsed)
 }}}

 A representative stat with a big TSO is

 {{{
 224198416 bytes, 425 GCs (415 + 10), 0/0 avg/max bytes residency (0
 samples), 853296496 bytes GC work, 426M in use, 0.00 INIT (0.00 elapsed),
 0.00 MUT (0.00 elapsed), 0.47 GC (0.47 elapsed), 0.12 GC(0) (0.12
 elapsed), 0.34 GC(1) (0.35 elapsed)
 }}}

 What I don't understand is why the memory in use blows up by 150MB; by my
 count, the extra words should only be adding something like 10MB of
 overhead; my best guess is that I am actually nudging TSO size over some
 invisible threshold (maybe the big object threshold).

 ----

 From there, the next two bugs have to do with subtle scheduler changes.
 The first bug I have a clean fix for (it was a plain old bug); 'sieve'
 slows down a lot if threads which HeapOverflow don't get put back in front
 of the run queue.  Fixing that dramatically improves runtime for all of
 the benchmarks except 'threads003': we can make that performance problem
 go away if we force threads to get appended to the end of the run queue
 (of course, stride scheduling won't work in that case!) I'm still
 investigating these.

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