Skip to content

rts: erroneous counting of parallel garbage collections with `-qn`

In #15897 (comment 345881) @jwaldmann shows an -RTS -s output reproduced here: (this ticket is about counting gen0 parallel collections, not the absurd GC time and productivity)

... +RTS -qn1 -N8 -M10g -p -h  -RTS

  26,442,284,496 bytes allocated in the heap
2,140,046,565,680 bytes copied during GC
     734,162,344 bytes maximum residency (97 sample(s))
       5,612,520 bytes maximum slop
            1483 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0     10019 colls, 10019 par   4024.705s   4.627s     0.0005s    0.0027s
  Gen  1        97 colls,    96 par   75.138s  48.021s     0.4951s    1.5685s

  Parallel GC work balance: 12.17% (serial 0%, perfect 100%)

  TASKS: 24 (1 bound, 23 peak workers (23 total), using -N8)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.008s  (  0.005s elapsed)
  MUT     time    0.000s  (  8.847s elapsed)
  GC      time  4081.967s  ( 34.590s elapsed)
  RP      time    0.000s  (  0.000s elapsed)
  PROF    time   17.875s  ( 18.058s elapsed)
  EXIT    time    0.022s  (  0.018s elapsed)
  Total   time   79.236s  ( 61.518s elapsed)

  Alloc rate    0 bytes per MUT second

  Productivity -5051.7% of total user, 43.7% of total elapsed

Note that it is run with -qn, which should disable parallel collections in gen0, however the report shows all gen0 collections are parallel.

This seems to be very similar to #19147 (closed)

In fact, I am almost certain the error is at https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.0.1-release/rts/sm/GC.c#L609, where this is not a valid way of determinining whether this was a parallel collection.

Edited by Ben Gamari
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information