[ltt-dev] [RFC for CTF] Storing state metadata

[Alexandre Montplaisir]

On 11-02-07 03:41 PM, Mathieu Desnoyers wrote:
>
>>>>     Points of interest
>>>> --------------------------
>>>>
>>>> * Integer vs Strings state values
>>>> The design of the State History so far allows for State values to be either
>>>> Integers or variable-length Strings. However, in cases where we have a defined
>>>> set of possible values known in advance, it might be interesting to use enum-
>>>> like integers instead of strings to save up on storage space. (e.g. system call
>>>> names, IRQ names, etc.)
>>>>
>>>> One thing to remember in this case is that the "mapping" between the enums and
>>>> the integers will have to be known by both the tracer and the analysis tool, so
>>>> this adds a dependency.
>>>> (The State History library does not need to know about it though, we can have it
>>>> store any value and it will happily return it without knowing what it means.)
>>> One possibility would be to keep one extra type of info: enums would be
>>> a ( value , reference to enumeration mapping table ) pair, so that the
>>> corresponding string could be extracted from the value without having to
>>> keep information about the enumeration mapping table externally. We
>>> could even decide to have a whole level of "directories" in the state
>>> tree mapped to a single enumeration mapping table, which would apply to
>>> all children, so we don't have to repeat the enum table reference. Just
>>> food for thoughts.
>>>
>> Yes that's a good idea. Those mappings would be different for each
>> application anyway, so it makes sense to make it part of the supplied
>> information.
>> They shouldn't be stored in the History per se (because it's not
>> interval-like information that can change during the trace), but could
>> come in another container for "static state information" that's valid
>> all the time?
> Not sure. We already have some data structures planned to keep these
> mappings that are invariant across all the trace. 

Oh, that's good to know.

> The point is mostly to
> be able to link the data (in the state history) to these mappings. I
> don't see why it would be inconvenient to keep this information inside
> the state history: it's just a state that has a duration of the whole
> trace, so it does not use much space.
>

Oh yes, it could be part of the "History" itself, I was just thinking
out loud saying it wouldn't be in the "State History Tree", the interval
data structure. (who came up with these confusing names anway, oh wait...)

Constant information isn't very interesting to store in the SHT because
it always resides in (and may end up clogging) the root node of the
tree. I could provide another container on the side to store the
mappings, and it could pull its data directly from the structures you
were talking about earlier.

>> Hmm, if I remember right, in this case it was to avoid creating
>> un-needed intervals when the CPUs weren't executing anything, and save a
>> bit of space. We could still know that "idle" was being executed as the
>> History would return "null".
> "idle" can actually execute things: interrupt handlers, management of
> swap, etc are executed on behalf of PID 0.

> I don't see how the current
> thread is set to NULL in your state update examples below; it seems to
> keep the previous thread as running.
>

Yeah now that you metion it... I think I broke something in the last
round of fixes.



Thanks a lot, I'll keep all those comments in mind for the next version.

-- 
Alexandre Montplaisir
DORSAL lab,
École Polytechnique de Montréal