Changes between Version 23 and Version 24 of RTSsummaryEvents

Timestamp:

01/07/12 17:11:06 (17 months ago)

Author:

MikolajKonarski (IP: 95.160.111.162)

Comment:

Include answers fromJaffaCake, continued, all answers from 5 Jan used up

RTSsummaryEvents

@@ -73 +73 @@
   Parallel GC work balance: 1.00 (6391526 / 6375794, ideal 2)
 }}}
-  
-This is computed in a quite convoluted way in the +RTS -s code. Ask JaffaCake if it could be simplified.
+
+Let's ignore that one for now.  
+JaffaCake says we probably don't care about work balance and that he thinks it is computed in the simplest way.
+Detail are in [http://community.haskell.org/~simonmar/papers/parallel-gc.pdf].
 The current computation seems to be the following: total words copied during parallel GCs divided
 by the average over all parallel GCs of maximal number of words copied
 by any thread in a single par GC. Events needed: the events added above probably suffice,
 but quite a bit of extra state will have to be maintained when reading
-the events, especially if we want to stick to the current, complex computation.
+the events, especially if we want to stick to the current, arguably complex, computation.
 
 {{{
@@ -89 +91 @@
 }}}
 
-Ask JaffaCake how the "tasks" relate to the "threads" for which we generate 
-events. For now, to the existing GC events we can add the info about which task
-does the job, but we may miss something this way. BTW, ask JaffaCake if the time between event GCIdle and GCWork is included
-in the GC time of the task or not. Generally, is GCIdle useful for us here in any way?
-Similarly, can we calculate the MUT (elapsed) times just but taking the total
-time a thread (or cap?) is run and subtracting the GC time and any pauses (and are all
-pauses visible through events we have already?).
+Let's ignore that one for now.  
+JaffaCake says the task information has questionable usefulness. It's much more natural for us to present the same info per cap, not per OS thread (which the tasks basically are). Actually we do present the GC info per cap (not only total, as in +RTS -s) already and the total activity time per cap (which includes the mutator time) is much better conveyed by the graphs in ThreadScope.
+
+BTW, the time between events GCIdle and GCWork is still counted as GC time, so we may ignore the events for calculating the times spent on GC. OTOH, a summary of the GCIdle times, per hec, then the total, also as the percentage of all GC time could be useful. Probably we can do that cheaply along the waym since we have to identify and sift out the GCIdle and GCWork events anyway.
 
 {{{