Changes between Version 24 and Version 25 of RTSsummaryEvents

Timestamp:

01/07/12 17:29:21 (17 months ago)

Author:

MikolajKonarski (IP: 95.160.111.162)

Comment:

clarifications and various clean up

RTSsummaryEvents

@@ -57 +57 @@
 so it's a difference between total memory allocated from the OS (peak_mblocks_allocated), 
 and total memory in use by the GC and other parts of the RTS (hw_alloc_blocks). 
-Presumably, all the events needed so far are of the latter kind, so the former may need a new event.
+Presumably, all the events needed so far are of the latter kind (really used), 
+so the former (allocated from the OS) may need a new event.
 
 {{{
@@ -67 +68 @@
 The current GC events (in particular RequestParGC) seem to be enough to distinguish 
 between seq and par GC. We'd need to split the current GC events into generations, though,
-to report for every generation separately. Note that we don't want 
+to report for every generation separately. We may and up with two tables for the same GC info:
+one aggregated by cap, another by generations. Note that we don't want 
 to report the CPU time, only the elapsed time, and that's fine.
 
@@ -81 +83 @@
 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, arguably complex, computation.
+the events due to the rather complex formula for work balance.
 
 {{{
@@ -91 +93 @@
 }}}
 
-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.
+JaffaCake says the task information has questionable usefulness, so let's ignore that one for now.  
+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.
+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 way since we have to identify and sift out the GCIdle, GCDone and GCWork events anyway.
 
 {{{