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

24 Jan 2013

      #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):

 Copied memory is affected disproportionately:

 {{{
 [ezyang@hs01 threads006]$ ./Main-big 200000 +RTS -s
      224,198,416 bytes allocated in the heap
      853,296,496 bytes copied during GC
      197,453,072 bytes maximum residency (10 sample(s))
       25,701,000 bytes maximum slop
              426 MB total memory in use (0 MB lost due to fragmentation)

 [ezyang@hs01 threads006]$ ./Main-medium 200000 +RTS -s
      224,198,416 bytes allocated in the heap
      690,756,096 bytes copied during GC
      125,998,552 bytes maximum residency (9 sample(s))
       24,121,032 bytes maximum slop
              270 MB total memory in use (0 MB lost due to fragmentation)
 }}}

 That's an over 150MB jump.

 I think I have an important clue, though; consider these three runs on the
 big TSO executable:

 {{{
 [ezyang@hs01 threads006]$ ./Main-big 182260 +RTS -s
      204,318,544 bytes allocated in the heap
      622,311,352 bytes copied during GC
      110,659,024 bytes maximum residency (9 sample(s))
       23,499,512 bytes maximum slop
              239 MB total memory in use (0 MB lost due to fragmentation)

 [ezyang@hs01 threads006]$ ./Main-big 182261 +RTS -s
      204,319,648 bytes allocated in the heap
      622,313,432 bytes copied during GC
      110,659,024 bytes maximum residency (9 sample(s))
       23,453,024 bytes maximum slop
              239 MB total memory in use (0 MB lost due to fragmentation)

 [ezyang@hs01 threads006]$ ./Main-big 182262 +RTS -s
      204,320,752 bytes allocated in the heap
      791,958,776 bytes copied during GC
      169,695,072 bytes maximum residency (10 sample(s))
       23,503,128 bytes maximum slop
              395 MB total memory in use (0 MB lost due to fragmentation)
 }}}

 Wow! In the case of the 182262th thread, it's literally the straw that
 broke the camel's back. I went ahead and logged GC events. The breakpoint
 occurs here:

 {{{
 ----------------------------------------------------------
   Gen     Max  Mut-list  Blocks    Large     Live     Slop
        Blocks     Bytes          Objects
 ----------------------------------------------------------
     0   53762         0       2        0     1184     7008
     1   53762         3   53766       94 196721432 23504104
 ----------------------------------------------------------
                                          196722616 23511112
 ----------------------------------------------------------

 Memory inventory:
   gen 0 blocks :     1 blocks (   0.0 MB)
   gen 1 blocks : 53766 blocks ( 210.0 MB)
   nursery      :   129 blocks (   0.5 MB)
   retainer     :     0 blocks (   0.0 MB)
   arena blocks :     0 blocks (   0.0 MB)
   exec         :     0 blocks (   0.0 MB)
   free         :  6332 blocks (  24.7 MB)
   total        : 60228 blocks ( 235.3 MB)
 alloc new todo block 0x7f13c7aff000 for gen  0
 alloc new todo block 0x7f13c7ca1000 for gen  1

 [snip]

 ----------------------------------------------------------
   Gen     Max  Mut-list  Blocks    Large     Live     Slop
        Blocks     Bytes          Objects
 ----------------------------------------------------------
     0   82858         0       2        0      104     8088
     1   82858         1   45569        3 169695176 16955448
 ----------------------------------------------------------
                                          169695280 16963536
 ----------------------------------------------------------

 Memory inventory:
   gen 0 blocks :     1 blocks (   0.0 MB)
   gen 1 blocks : 45569 blocks ( 178.0 MB)
   nursery      :   129 blocks (   0.5 MB)
   retainer     :     0 blocks (   0.0 MB)
   arena blocks :     0 blocks (   0.0 MB)
   exec         :     0 blocks (   0.0 MB)
   free         : 53841 blocks ( 210.3 MB)
   total        : 99540 blocks ( 388.8 MB)

 }}}

 Inside the snip, approximately a 100 hundred megablocks are allocated as
 TODO space for scavenge, ala

 {{{
 allocated 1 megablock(s) at 0x7f13b5a00000
 alloc new todo block 0x7f13b5a04000 for gen  1
 increasing limit for 0x7f13b5a04000 to 0x7f13b5a04800
 }}}

 It seems we run out of todo blocks while evacuating, and then essentially
 need to copy our entire heap. Ouch! Unfortunately, I don't know enough to
 say if this is a GC bug or not.

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