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,402
    • Issues 5,402
    • 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
Notes from meeting with Peter authored Jul 28, 2014 by kvelicka's avatar kvelicka
Hide whitespace changes
Inline Side-by-side
event-log/live-monitoring.md
View page @ b773a26e
......@@ -85,7 +85,7 @@ Foo is an abstraction / library (or libraries) that will use the new API of RTS
- RTS broadcasts on demand once a client connects
- Sockets seem to be appropriate for live monitoring
### 09/07/2014
### 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
......@@ -104,6 +104,46 @@ Foo is an abstraction / library (or libraries) that will use the new API of RTS
- 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
```
- 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
## Discussed APIs
......
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