Changes between Version 10 and Version 11 of RTSsummaryEvents

Show
Ignore:
Timestamp:
12/21/11 08:01:26 (3 years ago)
Author:
MikolajKonarski (IP: 95.160.111.162)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RTSsummaryEvents

    v10 v11  
    2121Either a separate event for that, perhaps emitted only after major GC, when we know how much memory 
    2222is really used by the program (the docs explain the "n samples" saying "only checked during major garbage collections").  
    23 Or try to calculate it from all events. in particular memory deallocation events or GC memory freeing events. 
     23Or try to calculate it (how often to sample?) from all events. in particular memory deallocation events or GC memory freeing events. 
    2424 
    2525{{{ 
     
    5858(if RequestParGC is not enough to tell seq/par). Note that we don't want  
    5959to report the CPU time, only the elapsed time, and that's fine. 
    60 With the current GC events only summarized information is available. 
    6160 
    6261{{{ 
     
    7978 
    8079Ask JaffaCake how the "tasks" relate to the "threads" for which we generate  
    81 events. Perhaps in the existing GC evens add the info about which task 
     80events. Perhaps to the existing GC events we can add the info about which task 
    8281does the job. BTW, is the time between event GCIdle and GCWork counted 
    8382as GC time of the task? Generally, is GCIdle useful for us here in any way? 
     
    105104 
    106105(Note that there may be more positions here, e.g., for profiling.) 
    107 We can sum up the times from GC events. For other stats, we'd need the MUT 
    108 figure, but it's not obvious if we manage to get it from all the thread (task) 
    109 events that we have and will add above. It's also not clear if adding events 
    110 needed to get the other times is worth it. After all the other events 
     106We can sum up the GC time from GC events. We'd also like to have the MUT 
     107figure, but it's not obvious if we can manage to get it from all the thread (task) 
     108events that we have (or add above). It's also not clear if adding events 
     109needed to get the other times is worth it. After any extra events 
    111110are added, let's see if we can get any more of these summary times, 
    112111perhaps by adding a minor event emitted just once. Note that the INIT time is 
    113 necessary for the Productivity figure below (it does not count as "productive 
     112necessary for the Productivity figure below (INIT does not count as "productive 
    114113time" in +RTS -s).. 
    115114 
     
    132131}}} 
    133132 
    134 The events added above should be enough. Again. we only do the elapsed case. 
     133The events added above should be enough. Again. we only do the elapsed case.  
     134Ask JaffaCake if it's OK that the "% of total elapsed" in +RTS -s is actually the CPU time divided by elapsed time.