Changes between Version 24 and Version 25 of RTSsummaryEvents

Show
Ignore:
Timestamp:
01/07/12 17:29:21 (3 years ago)
Author:
MikolajKonarski (IP: 95.160.111.162)
Comment:

clarifications and various clean up

Legend:

Unmodified
Added
Removed
Modified
  • RTSsummaryEvents

    v24 v25  
    5757so it's a difference between total memory allocated from the OS (peak_mblocks_allocated),  
    5858and total memory in use by the GC and other parts of the RTS (hw_alloc_blocks).  
    59 Presumably, all the events needed so far are of the latter kind, so the former may need a new event. 
     59Presumably, all the events needed so far are of the latter kind (really used),  
     60so the former (allocated from the OS) may need a new event. 
    6061 
    6162{{{ 
     
    6768The current GC events (in particular RequestParGC) seem to be enough to distinguish  
    6869between seq and par GC. We'd need to split the current GC events into generations, though, 
    69 to report for every generation separately. Note that we don't want  
     70to report for every generation separately. We may and up with two tables for the same GC info: 
     71one aggregated by cap, another by generations. Note that we don't want  
    7072to report the CPU time, only the elapsed time, and that's fine. 
    7173 
     
    8183by any thread in a single par GC. Events needed: the events added above probably suffice, 
    8284but quite a bit of extra state will have to be maintained when reading 
    83 the events, especially if we want to stick to the current, arguably complex, computation. 
     85the events due to the rather complex formula for work balance. 
    8486 
    8587{{{ 
     
    9193}}} 
    9294 
    93 Let's ignore that one for now.   
    94 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. 
     95JaffaCake says the task information has questionable usefulness, so let's ignore that one for now.   
     96It's much more natural for us to present the same info per cap,  
     97not per OS thread (which the tasks basically are). Actually we do present the GC info per cap (not only total, as in +RTS -s)  
     98already and the total activity time per cap (which includes the mutator time) is much better conveyed by the graphs in ThreadScope. 
    9599 
    96 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. 
     100BTW, the time between events GCIdle and GCWork is still counted as GC time, so we may ignore the events for calculating  
     101the 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.  
     102Probably we can do that cheaply along the way since we have to identify and sift out the GCIdle, GCDone and GCWork events anyway. 
    97103 
    98104{{{