Hello,
I am currently analyzing the Google workload traces with the cache simulator.
Here, I am interested in analyzing the LLC miss rate, and I have extended the cache simulator to also recognize timestamp markers and record the timestamped-LLC misses. As I want to keep the Google traces in order w.r.t. to their timestamps in the cache simulator (I do not want to simulate them on a different machine, but I want to understand how the application behaved in the data center), I am using a single CPU core (i.e., using the parameter '-cores 1'). This resolved my initial issue of seeing timestamps for LLC misses being out-of-order (i.e., younger timestamps were seen before older timestamps).
Initially, I was using 100 traces and I used the first and the last timestamp to compute an execution time for the application. The execution time here was 3.1 seconds.
When I extended the experiment to 600 traces (the initial 100 traces are part of that set), I got an execution time of 2.8 seconds using the timestamps. That is, adding more traces lead to a reduced execution time of 300ms, which should not be possible. I then found that the scheduler is 'updating' the timestamps.
I now have multiple questions:
- Why are the original timestamps modified?
- If I want to use the original timestamps, can I simply do that to perform a time-based analysis (an approximated one is fine, too)?
- Is my approach of using a single CPU core in the cache simulator reasonable to enforce an in-order execution w.r.t. the timestamps?
I just started using DynamoRIO, so feel free to point out any horrific mistakes I have made.
Thanks and best regards,
Linus