1. 16 Oct, 2017 1 commit
  2. 11 Jul, 2017 1 commit
    • duog's avatar
      Fix Work Balance computation in RTS stats · 7c9e356d
      duog authored
      An additional stat is tracked per gc: par_balanced_copied This is the
      the number of bytes copied by each gc thread under the balanced lmit,
      which is simply (copied_bytes / num_gc_threads).  The stat is added to
      all the appropriate GC structures, so is visible in the eventlog and in
      GHC.Stats.
      
      A note is added explaining how work balance is computed.
      
      Remove some end of line whitespace
      
      Test Plan:
      ./validate
      experiment with the program attached to the ticket
      examine code changes carefully
      
      Reviewers: simonmar, austin, hvr, bgamari, erikd
      
      Reviewed By: simonmar
      
      Subscribers: Phyx, rwbarton, thomie
      
      GHC Trac Issues: #13830
      
      Differential Revision: https://phabricator.haskell.org/D3658
      7c9e356d
  3. 29 Apr, 2017 1 commit
  4. 12 Oct, 2013 1 commit
  5. 15 Oct, 2012 1 commit
    • Duncan Coutts's avatar
      Add a new traceMarker# primop for use in profiling output · a609027d
      Duncan Coutts authored
      In time-based profiling visualisations (e.g. heap profiles and ThreadScope)
      it would be useful to be able to mark particular points in the execution and
      have those points in time marked in the visualisation.
      
      The traceMarker# primop currently emits an event into the eventlog. In
      principle it could be extended to do something in the heap profiling too.
      a609027d
  6. 10 Jul, 2012 2 commits
    • Duncan Coutts's avatar
      Have a go at fixing the heap info DTrace build failue on OSX · 45c80482
      Duncan Coutts authored
      This patch will need to be tested by someone on OSX.
      
      Fixed a couple wrong names:
        CapsetID vs EventCapsetID
        gc__sync vs gc__global__sync
      45c80482
    • Duncan Coutts's avatar
      Define the task-tracking events · 54c98b68
      Duncan Coutts authored
      Based on initial patches by Mikolaj Konarski <mikolaj@well-typed.com>
      
      These new eventlog events are to let profiling tools keep track of all
      the OS threads that belong to an RTS capability at any moment in time.
      In the RTS, OS threads correspond to the Task abstraction, so that is
      what we track. There are events for tasks being created, migrated
      between capabilities and deleted. In particular the task creation event
      also records the kernel thread id which lets us match up the OS thread
      with data collected by others tools (in the initial use case with
      Linux's perf tool, but in principle also with DTrace).
      54c98b68
  7. 10 Apr, 2012 1 commit
  8. 04 Apr, 2012 3 commits
    • Mikolaj Konarski's avatar
      Add the GC_GLOBAL_SYNC event marking that all caps are stopped for GC · c294d95d
      Mikolaj Konarski authored
      Quoting design rationale by dcoutts: The event indicates that we're doing
      a stop-the-world GC and all other HECs should be between their GC_START
      and GC_END events at that moment. We don't want to use GC_STATS_GHC
      for that, because GC_STATS_GHC is for extra GHC-specific info,
      not something we have to rely on to be able to match the GC pauses
      across HECs to a particular global GC.
      c294d95d
    • Duncan Coutts's avatar
      Add new eventlog events for various heap and GC statistics · 65aaa9b2
      Duncan Coutts authored
      They cover much the same info as is available via the GHC.Stats module
      or via the '+RTS -s' textual output, but via the eventlog and with a
      better sampling frequency.
      
      We have three new generic heap info events and two very GHC-specific
      ones. (The hope is the general ones are usable by other implementations
      that use the same eventlog system, or indeed not so sensitive to changes
      in GHC itself.)
      
      The general ones are:
      
       * total heap mem allocated since prog start, on a per-HEC basis
       * current size of the heap (MBlocks reserved from OS for the heap)
       * current size of live data in the heap
      
      Currently these are all emitted by GHC at GC time (live data only at
      major GC).
      
      The GHC specific ones are:
      
       * an event giving various static heap paramaters:
         * number of generations (usually 2)
         * max size if any
         * nursary size
         * MBlock and block sizes
       * a event emitted on each GC containing:
         * GC generation (usually just 0,1)
         * total bytes copied
         * bytes lost to heap slop and fragmentation
         * the number of threads in the parallel GC (1 for serial)
         * the maximum number of bytes copied by any par GC thread
         * the total number of bytes copied by all par GC threads
           (these last three can be used to calculate an estimate of the
            work balance in parallel GCs)
      65aaa9b2
    • Duncan Coutts's avatar
      Add eventlog/trace stuff for capabilities: create/delete/enable/disable · f9c2e854
      Duncan Coutts authored
      Now that we can adjust the number of capabilities on the fly, we need
      this reflected in the eventlog. Previously the eventlog had a single
      startup event that declared a static number of capabilities. Obviously
      that's no good anymore.
      
      For compatability we're keeping the EVENT_STARTUP but adding new
      EVENT_CAP_CREATE/DELETE. The EVENT_CAP_DELETE is actually just the old
      EVENT_SHUTDOWN but renamed and extended (using the existing mechanism
      to extend eventlog events in a compatible way). So we now emit both
      EVENT_STARTUP and EVENT_CAP_CREATE. One day we will drop EVENT_STARTUP.
      
      Since reducing the number of capabilities at runtime does not really
      delete them, it just disables them, then we also have new events for
      disable/enable.
      
      The old EVENT_SHUTDOWN was in the scheduler class of events. The new
      EVENT_CAP_* events are in the unconditional class, along with the
      EVENT_CAPSET_* ones. Knowing when capabilities are created and deleted
      is crucial to making sense of eventlogs, you always want those events.
      In any case, they're extremely low volume.
      f9c2e854
  9. 04 Nov, 2011 1 commit
    • Duncan Coutts's avatar
      Add eventlog event for thread labels · c739d845
      Duncan Coutts authored
      The existing GHC.Conc.labelThread will now also emit the the thread
      label into the eventlog. Profiling tools like ThreadScope could then
      use the thread labels rather than thread numbers.
      c739d845
  10. 20 Jul, 2011 1 commit
  11. 18 Jul, 2011 2 commits
    • Duncan Coutts's avatar
      Add new fully-accurate per-spark trace/eventlog events · 084b64f2
      Duncan Coutts authored
      Replaces the existing EVENT_RUN/STEAL_SPARK events with 7 new events
      covering all stages of the spark lifcycle:
        create, dud, overflow, run, steal, fizzle, gc
      
      The sampled spark events are still available. There are now two event
      classes for sparks, the sampled and the fully accurate. They can be
      enabled/disabled independently. By default +RTS -l includes the sampled
      but not full detail spark events. Use +RTS -lf-p to enable the detailed
      'f' and disable the sampled 'p' spark.
      
      Includes work by Mikolaj <mikolaj.konarski@gmail.com>
      084b64f2
    • Duncan Coutts's avatar
      Add spark counter tracing · d77df1ca
      Duncan Coutts authored
      A new eventlog event containing 7 spark counters/statistics: sparks
      created, dud, overflowed, converted, GC'd, fizzled and remaining.
      These are maintained and logged separately for each capability.
      We log them at startup, on each GC (minor and major) and on shutdown.
      d77df1ca
  12. 26 May, 2011 1 commit
    • Duncan Coutts's avatar
      Add capability sets to the tracing/events system · 43c7d555
      Duncan Coutts authored
      We trace the creation and shutdown of capabilities. All the capabilities
      in the process are assigned to one capabilitiy set of OS-process type.
      
      This is a second version of the patch. Includes work by Spencer Janssen.
      43c7d555
  13. 22 May, 2011 1 commit
  14. 18 May, 2011 1 commit
  15. 27 Jan, 2011 1 commit
  16. 12 Jan, 2011 1 commit
  17. 12 Dec, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Expose all EventLog events as DTrace probes · 015d3d46
      chak@cse.unsw.edu.au. authored
      - Defines a DTrace provider, called 'HaskellEvent', that provides a probe
        for every event of the eventlog framework.
      - In contrast to the original eventlog, the DTrace probes are available in
        all flavours of the runtime system (DTrace probes have virtually no
        overhead if not enabled); when -DTRACING is defined both the regular
        event log as well as DTrace probes can be used.
      - Currently, Mac OS X only.  User-space DTrace probes are implemented
        differently on Mac OS X than in the original DTrace implementation.
        Nevertheless, it shouldn't be too hard to enable these probes on other
        platforms, too.
      - Documentation is at http://hackage.haskell.org/trac/ghc/wiki/DTrace
      015d3d46