4 ms·

This is totally doable. PANDA [1], e.g., takes recordings of full-system execution by recording non-deterministic hardware inputs in a modified QEMU. This is mu

by moyix 10y ago

This is totally doable. PANDA [1], e.g., takes recordings of full-system execution by recording non-deterministic hardware inputs in a modified QEMU. This is much more compact than a full instruction trace, but you can then replay the recording to produce instruction traces, memory traces, whatever. We recently added some machinery [2] for using debug symbols to map each instruction back to its source line. So, assuming you can get debug symbols installed for every userspace program, every library, and the kernel, I think you could come very close to tying every instruction back to a source line. There are caveats, though – the overhead of QEMU and the recording infrastructure mean you only end up getting around 200 million instructions / second, which is nothing compared to modern bare metal. You could capture a longer trace, though, and do the same thing to get up to the same amount of code executed as on real hardware. If someone wants to try this I'd be very interested to see the results and happy to help answer any questions that come up! [1] https://github.com/moyix/panda https://github.com/moyix/panda [2] https://github.com/moyix/panda/blob/master/qemu/panda_plugins/pri_trace/pri_trace.cpp https://github.com/moyix/panda/blob/master/qemu/panda_plugin...

pm215 10y ago
This is getting perilously close to "attempting to extract performance information from a program running under a simulator/CPU model", which is really tricky to do in a way that gives you results that apply to actual hardware. In particular, the performance characteristics of QEMU are wildly different from real hardware in several significant ways: (1) the emulated FPU is incredibly slow, so the results will overweight anything that's FP-intensive (2) there is no modelling of CPU caches, TLBs or branch predictors, so these major influences on real-hardware performance won't be visible (3) because the emulated CPU is very slow, interrupt handler and similar code which runs triggered by timers or other external events will take up more time in the trace than it would on hardware. You'd probably find something interesting in the general sense from looking at what's going on in a QEMU emulation for a fixed time period, but you'd need to be rather wary about how applicable what you saw might be to a real hardware run. At minimum you'd want to cross-check against what perf on real hardware revealed.

by moyix 10y ago

pm215 10y ago

This is getting perilously close to "attempting to extract performance information from a program running under a simulator/CPU model", which is really tricky to do in a way that gives you results that apply to actual hardware. In particular, the performance characteristics of QEMU are wildly different from real hardware in several significant ways: (1) the emulated FPU is incredibly slow, so the results will overweight anything that's FP-intensive (2) there is no modelling of CPU caches, TLBs or branch predictors, so these major influences on real-hardware performance won't be visible (3) because the emulated CPU is very slow, interrupt handler and similar code which runs triggered by timers or other external events will take up more time in the trace than it would on hardware. You'd probably find something interesting in the general sense from looking at what's going on in a QEMU emulation for a fixed time period, but you'd need to be rather wary about how applicable what you saw might be to a real hardware run. At minimum you'd want to cross-check against what perf on real hardware revealed.