event-log/live-monitoring.md

@@ -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()