On 03/03/2011 12:02, Duncan Coutts wrote:
Attached is
Thu Mar 3 11:30:52 GMT 2011 Duncan Coutts<[email protected]>
* Mark the event number ranges reserved by eden
And add a few other explanitory comments.
Thu Mar 3 11:33:04 GMT 2011 Duncan Coutts<[email protected]>
* Add new capability set concept to the event/trace system
Capability sets are a bit of new infrastructure for the ghc
event/trace system that hopefully is reasonably generic and will
have multiple uses.
A capability set is just a set of capabilities. Some information
that we would like to emit in an event log should be attached not
to an individual Haskell thread or RTS capability, but should be
identified with a certain set of RTS capabilities. For example the
OS process ID is identified with all the capabilities in the RTS
instance. The OS PID is not global however: we wish to merge event
logs from multiple processes (either concurrent processes or from
multiple runs of the same process). A capability set (capset)
provides a context to attach such information.
This patch adds the basic events for keeping track of capability
sets. It exposes them both in the event log and via dtrace.
At this stage I'm mainly seeking feedback on whether I've got the
layering right. The GHC event/trace system has an events layer, a
tracing layer and dtrace layer. The capability set stuff itself is not
really tracing, it is not something that already happens in the RTS,
however it's a way of representing a context that will be used by some
events we plan to add. So we want this info in both the event log and in
the dtrace layer. I also added it in the debug tracing stuff, but it's
not obvious that that's needed.
Unlike scheduler events, the capset events are emitted unconditionally.
This is because they define information/context that will be reused by
events from multiple trace subsystems (beyond the current single
category of scheduler events). The simplest thing to do therefore is
just to emit these events unconditionally. They should be pretty low
volume, unless users/libs start using them heavily.
It's a little bit fishy, because the types EventCapsetID and EventCapNo
are exposed via the Trace.h API. The Event layer is supposed to be
hidden at this level. If EventCapsetID and EventCapsetType are concepts
that need to be visible outside of the Event layer, they should be moved
and given non-Event names. I admit it's a little confusing because
Trace uses Event types and constants internally, but they are only internal.
I thought we were going to keep the Capset stuff in the Event layer and
not expose it through Trace? Why does it need to be exposed via Trace?
Cheers,
Simon
Duncan
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
