> - 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, 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... 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. _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
