Re: [linuxtools-dev] [TMF] Advanced statistics view

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

On 13-02-12 08:18 AM, Michel Dagenais wrote:
>> - If you fall on a "real" interval, you know you are in a time where the
>> process was active on the CPU. You will need to do the interpolation
>> between the value (which represents the cumulative amount at the
>> start of the interval), the length of the interval, and the current
>> position in the interval itself. Note this does not require any extra query to
>> the state system, because a query returns you the whole interval now.
>> - If you fall on a null value, this means the process was not on the
>> CPU. To get its cumulative CPU time, get the previous interval (query
>> at "interval.startTime - 1"), get the value of that interval + its length.
>> This will give you the cumulative time at the end of that interval,
>> which stays constant for the whole null interval too.
> Clever, 
I blame our masters supervisor.
> this method only requires a single "attribute" to store the cumulative time and whether or not the process is in an active interval. Its value is changed at schedule in and at schedule out. However, you need to do additional queries. For instance, if you want to show the CPU usage per process for an interval t0,t1 (pixel on screen), you need the query at t0 and t1 and, for each process, you need as well values at their respective interval.startTime -1, leading to an additional query for each process...
Yes, this is an issue, I think since the number of processes is
relatively small (under 65535 or in reality under 1k) and for a given
time slice most threads/processes would not change,  this may or may not
be a performance issue. It should be benchmarked.
>
> One possible alternative is to store the cumulative CPU time in one attribute and the entryTime for the current interval if scheduled in and thus ongoing (or NULL if scheduled out). This would be 2 attributes instead of 1 in the current state, 1 change at schedule in and 2 at schedule out (thus 3 changes instead of 2 in the history). However, you would not need any of the additional queries and there should be no problem with partial history storage optimizations.
Yes, this is an interesting idea. About the partial history vs full
history, this is something where partial history IMO is not at all
beneficial since the intervals are large and the changing events are few
and far between, relatively on the kernel front.  this state system
takes (empirically) approx 10 mb, 20 mb for the new system for every gb
of the full state system, so trying compression to save space here is
like trying to balance the US economy by cutting PBS's funding. Alex
will probably disagree with me here.

With very very large traces, I can't tell if this state system will be
larger than say a partial stats history tree. I think some investigation
is needed.

Thanks for the feedback
PS, do you know why when you reply to a thread, it goes to the root
instead of appending to the end of the mail chain? I think there's a bug
with zimbra.

> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev