[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-tcf-dev] Need for a general "Properties" service?
|
> If you look at the data transmission that
> is needed by products such as LTTng and various commercial "event
> analyzers" that many of us sell, it basically comes down to a stream
> of events that have all have:
> -event id (what kind of event is it?)
> -timestamp (of various flavors)
> -context (board/core/process/thread)
> -event specific data (a mutex lock event might have mutex id and
> current recursion count or something)
Yes. Here are some examples of "variations" which affect complexity and compactness:
- you can have per core/process/thread buffers and associated tracefiles, obviating the need to store some of that information with each event.
- if you have scheduling events, you dont need the process id in each event.
- the timestamp length may be shorter if you can get the high order bits in some other way once in a while, for instance with a heartbeat event or clock interrupt.
- the event id may be global or local to a tracing "channel". How about new events defined in a kernel module loaded after tracing has started? Are ids dynamically assigned, recycled?
> I am hoping we can
> create an open protocol for this type of event data that has the following
> sorts of attributes:
> -must be efficient for transmission of gigabytes of data (i.e.
> binary...)
> -flexible notion of time stamping (wall clock, cpu cycle count,
> "approximate" flag, etc)
> -flexible notion of a context
> -Arbitrary event specific data (integers, floats, strings, addresses
> ,etc)
> -Possibly integrated compression scheme(s)
> -priority of transmission is managed somehow (so sending the
> gigabytes of data doesn't starve other services)
Yes, I very much agree. How do you want to go about it? It would be interesting to look at what Ftrace in the mainline Linux kernel does, what the LTTng patches add, and what the Mentor proprietary binary protocol does better/differently. Wind River probably has interesting thoughts/examples on the topic as well. The outcome would ideally be a simple yet efficient and flexible protocol/format for tracing. From there we could "extend" the Linux mainline tracing facility, subsuming Ftrace and LTTng. Then, other operating systems could also adapt to produce equivalent traces, all compatible with the Eclipse Tracing and Monitoring Framework.
