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