Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,400
    • Issues 5,400
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 590
    • Merge requests 590
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Wiki
  • Event log
  • live monitoring

live monitoring · Changes

Page history
Removed some meeting notes authored Sep 01, 2014 by kvelicka's avatar kvelicka
Hide whitespace changes
Inline Side-by-side
event-log/live-monitoring.md
View page @ deba76db
......@@ -41,79 +41,22 @@ Basic demo of live monitoring using above new features:
## Notes from meetings
### Initial
- In current state, RTS writes to the eventlog asynchronously.
- Need a new module in RTS for start/stop event logging
- RTS and GHC.RTS talk together via foreign ccalls
- Start/stop of logging would need to stop the HECs for sync. Need to measure the performance of this
- Peter: Stop HECs for sync: Could request a global GC for this? That gives you RTS-wide synchronization for free, and doing a GC is probably (?) cheap enough.
- During this we need to traverse threads in struct generation_, they are in global variable called generations. Also look into StgTSO (thread structures)
- Flushing only needs to flush inactive buffers (that are also not empty)
- Possibly add some GC events (some are currently in tracegc at the moment):
- heap size
- heap live
- RTS broadcasts on demand once a client connects
- Sockets seem to be appropriate for live monitoring
### 09/07/2014 (Duncan)
- Start/stop of streaming is different from the "sync events" mentioned in goals
- The details for the middleware library (Foo) are not that relevant now, focus should be on RTS level
- Available event classes are in Trace.h
- cassava CSV library is a good example that uses an incremental parser
- ErrorT may no longer be necessary (at least in the case of ErrorT String)
- Need info on events w.r.t. blocks and capabilities for the purpose of sorting
- Eventlogs are comprised of event blocks that belong to a certain capability plus some global events
- Look at Trace.{h, c}
- Trace has two levels:
- Tracing has two levels:
- "Tracing" - more general, prints to stderr, used for debugging
- "Event" - lives in RTS/Eventlog, used for writing \*.eventlog files
- Need to read/understand:
- includes/rts/EventLogFormat.h
- [EventLog](event-log).{h, c}
### 25/07/14 (Peter)
- Stop HECs for sync: Could request a global GC for this? That gives you RTS-wide synchronization for free, and doing a GC is probably (?) cheap enough.
- Random thought: The "tracing" / "eventlog" split feels like a bit of a relic. Maybe we could now replace the tracing back-end that reads the event-log via socket and produces the old tracing messages? Probably out of scope for you, but this is where we might be going at some point.
- enableEvents needs room for arguments as well as "flags". Context (edited for brevity):
```wiki
kvelicka:
- enableEvents / disableEvents: Don't want to make it more complicated than it needs to be, but for profiling I would have a good couple of different configurations, not even counting configurable sampling delays. Is there a strong reason that we need to make the interface a bit map? Also - wouldn't it be make more sense if the consumer could decide what messages it wants to receive?
are you suggesting that there's no reason for this currently? or is it something about bit vectors specifically that you don't like?
petermw:
Hm, maybe the other way around - what was the intended use for those functions? We are talking essentially about "+RTS -ls", right?
So the idea here is that this RTS option calls these functions, and then does what?
Suppresses the messages? Wouldn't it be easier to make sure the messages aren't generated in the first place?
Bottom line is maybe that I'm a bit confused why this is in the interface to begin with. Only reason I could think of is that you intended to have a central place to change these settings at run-time :)
kvelicka:
having everything in one place makes it easier to run the thing, especially if you want to change the event logger settings on the same running program
petermw:
https://github.com/scpmw/ghc/blob/profiling-ncg/rts/RtsFlags.c#L1657
This is what reads these flags currently
So the idea here is that instead of, say, "RtsFlags.TraceFlags.scheduler = rtsTrue" we compose some sort of bitmap, then pass it to the eventlog, which presumably unpacks it and sets the very same flag? :)
Well, for my profiling I have options like "-Ey100000"
Which would activate generation of cycle sampling messages with a period of 100000 cycles
That's not something that would fit into a simple "on/off" scheme
It's a flag with arguments essentially. I would like something along the lines of enableEvents(type, param, ...) and disableEvents(type) more
The "full" parameterisation here would be enableEvents(ET_SAMPLES, SAMPLE_INSTRUCTION_POINTER, SAMPLE_BY_SAMPLES, 100000);
Because theoretically we might also sample by cost-centres - and I probably wouldn't want another "type" for every single performance metric that perf_events offers
```
- enableEvents needs room for arguments as well as "flags".
- Event should hold its parent Capability in itself, having CapEvents is redundant (may be out of scope for my project)
- Headers are not used by users of ghc-events
Possible solutions to remove EventBlock:
- Yeah, the easiest implementation would be IORef (Seq CapEvent), or something along those lines
- Maybe IORef \[CapEvent\] is enough as well
## Proposed APIs
......@@ -248,7 +191,7 @@ flushEventLog(int ms);
```
ghc/base side:
Haskell implementation:
```wiki
initEventLogging:: IO()
......
Clone repository Edit sidebar
  • Adventures in GHC compile times
  • All things layout
  • AndreasK
  • AndreasPK
  • Back End and Run Time System
  • Backpack refactoring
  • Backpack units
  • Brief Guide for Compiling GHC to iOS
  • Building GHC on Windows with Stack protector support (SSP) (using Make)
  • CAFs
  • CafInfo rework
  • Compiling Case Expressions in ghc
  • Compiling Data.Aeson Error
  • Contributing a Patch
  • Core interface section
View All Pages