[ltt-dev] [RFC] CTF TSDL: clocks and dynamic enumerations

[Aaron Spear]

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