On Wed, 12/10 21:33, Bryan D. Payne wrote: > > By "evidence", I mean actual numbers for actual QEMU code. Nothing > >> sophisticated, just use your new interface in a way you consider > >> relevant for your own use case, then approximate this use with existing > >> interfaces. The approximation can be very rough. For instance, showing > >> that doing the whole job with your approach is a much faster than doing > >> a necessary part of the job with existing commands would do. > >> > > > > Sure, I can put together some numbers to help with this discussion. > > > > I've done some performance testing on my laptop. I have setup LibVMI to > access KVM guest memory using one of three different options: > > QMP/pmemsave (dump bytes to a file and then read that back into memory) > HMC/xp command (dump bytes via human monitor command and repack the output > to binary form) > QMP/pmemaccess (access bytes through a Unix socket, this is the patch we > are discussing in this thread) > > For each of these I measured the time required to translate a guest kernel > virtual address into a guest physical address. This is done with a 64-bit > Ubuntu Trusty guest and the addresses are translated by walking the page > tables in the guest using the selected memory access technique. > > You can see the graph here: > http://cl.ly/image/322a3s0h1V05 > > For those that prefer text, here's the numbers (in microseconds): > QMP/pmemsave: 77706 > HMC/xp command: 92552 > QMP/pmemaccess: 95 > > As you can see, the technique proposed in this patch is about 3 orders of > magnitude faster than the options available in Qemu today. I will also > note that this is for a _single_ virtual address translation. A typical > introspection application will be doing much more work than this, which > will only compound the problem. > > Hopefully this helps to explain why I believe that this is an improvement > to the existing mechanisms. Please let me know if you have any questions > about these results. > > I'll continue some exploration of doing the pmemaccess bulk data transfer > over QMP, instead of the UNIX socket. And I'll report back here once I've > come up with some thoughts on the best way to proceed. >
Look good. I believe QMP will be in between, and if it doesn't work as well, could you also try to use QEMU's char dev instead of limit this to unix socket? Fam
