Changes between Version 23 and Version 24 of RTSsummaryEvents

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

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

Legend:

Unmodified
Added
Removed
Modified
  • RTSsummaryEvents

    v23 v24  
    7373  Parallel GC work balance: 1.00 (6391526 / 6375794, ideal 2) 
    7474}}} 
    75    
    76 This is computed in a quite convoluted way in the +RTS -s code. Ask JaffaCake if it could be simplified. 
     75 
     76Let's ignore that one for now.   
     77JaffaCake says we probably don't care about work balance and that he thinks it is computed in the simplest way. 
     78Detail are in [http://community.haskell.org/~simonmar/papers/parallel-gc.pdf]. 
    7779The current computation seems to be the following: total words copied during parallel GCs divided 
    7880by the average over all parallel GCs of maximal number of words copied 
    7981by any thread in a single par GC. Events needed: the events added above probably suffice, 
    8082but quite a bit of extra state will have to be maintained when reading 
    81 the events, especially if we want to stick to the current, complex computation. 
     83the events, especially if we want to stick to the current, arguably complex, computation. 
    8284 
    8385{{{ 
     
    8991}}} 
    9092 
    91 Ask JaffaCake how the "tasks" relate to the "threads" for which we generate  
    92 events. For now, to the existing GC events we can add the info about which task 
    93 does the job, but we may miss something this way. BTW, ask JaffaCake if the time between event GCIdle and GCWork is included 
    94 in the GC time of the task or not. Generally, is GCIdle useful for us here in any way? 
    95 Similarly, can we calculate the MUT (elapsed) times just but taking the total 
    96 time a thread (or cap?) is run and subtracting the GC time and any pauses (and are all 
    97 pauses visible through events we have already?). 
     93Let's ignore that one for now.   
     94JaffaCake 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. 
     95 
     96BTW, 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. 
    9897 
    9998{{{