Hi Mathieu,
Some thoughts about clocks below:
> * Clock description
>
> So now about the clock description, I talked a little bit with Brian
> about this. The idea is to describe the relationship between the various
> time and ordering references available on a system as a simple
> description in the TSDL metadata. Some ideas on how to express this
> (note: the "clock {}" description is just made up as I thought it.
> Feedback would be welcome)
>
>
> event {
> name = timer_tick; /* or sync_point... */
> id = 3;
> fields := {
> uint64_t monotonic_value;
> uint64_t tsc_value;
> uint32_t seqnum;
> };
> };
>
> event {
> name = freq_change;
> id = 4;
> fields := {
> uint64_t new_freq;
> };
> };
>
> clock {
> name = monotonic;
> uuid = /* some unique identifier specific to this board's clock */;
> };
>
> clock {
> name = seqnum;
> uuid = /* some unique identifier specific to this board's clock */;
> };
>
> clock {
> name = tsc;
> sync_points = {
> map {
> parent.clock = monotonic;
> parent.value = event.timer_tick.monotonic_value;
> value = event.timer_tick.tsc_value;
> };
> map {
> parent.clock = seqnum;
> parent.value = event.timer_tick.seqnum;
> value = event.timer_tick.tsc_value;
> };
> };
>
> freq = {
> update = event.freq_change.new_freq;
> };
> uuid = /* some unique identifier specific to this board's clock */;
> };
One thing you did not describe is how a given stream of events references a
given clock. Do they refer to a clocks UUID? One concept that I think is
important here is to articulate different methods to access the same clock.
i.e. what if you have a shared global clock in a system but for one trace
stream access is very fast and for another there is some delay possible (e.g.
having to cross a slow bus). I have been thinking it would be useful to
decompose the clocks into a declaration and then an access for that clock.
Event streams then would be declared to reference a given clock_access. E.g.
clock {
name = shared_sys_clock;
freq = /* some constant or attribute like you have above */;
uuid = 12345; /* some unique identifier specific to this clock */;
};
clock_access {
name = shared_sys_clock_via_pci;
clock_uuid = 12345; /* reference to the UUID of the clock we are accessing
*/;
uuid = 23456; /* some unique identifier specific to this particular access
method for this particular clock */;
latency_min = 5us; /* what is the minimum time it takes to read this
clock? */
latency_max = 500us; /* what is the maximum time it takes to read this
clock? */
};
If you do this, then you can have the possibility of knowing that two different
trace streams reference the same clock source and the possible error involved
with accessing those clocks.
I must confess that I am not clear on your intent with how the sync point
events would work. That said, wouldn't we want to actually decouple the sync
points from the clock declarations? It seems like it might be better to have
those outside of the clock declaration so that it is possible for information
outside of the OS for example to declare relationships. Or perhaps one
component (e.g. power management) might know the relationship between the
clocks, but another one might not. Perhaps just specifying a type of event
that is known to be a clock sync event, and then attributes that are UUIDs of
the clocks and the corresponding values. Note that I am thinking that a sync
event is the synchronization of multiple clocks as opposed to changing the
values of the clocks (i.e. changing the frequency or the current count)
Regards,
Aaron Spear
VMware
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
