On Thu, 12/11 20:28, Bryan D. Payne wrote: > > > > > For those that prefer text, here's the numbers (in microseconds): > > > QMP/pmemsave: 77706 > > > HMC/xp command: 92552 > > > QMP/pmemaccess: 95 > > > > I completed a proof of concept implementation for doing this memory access > completely over QMP. Basically, it works much like pmemsave except instead > of sending the data to a file it does a base64 encode and sends it back > over the QMP connection. Interestingly, my testing shows that this is > slightly slower than the pmemsave option. Running the same test as before > (virtual address translation), I get 88063 microsecs on average. So I > don't believe this option is viable.
How did you setup your QMP, and how does the QMP transactions look like in your test? Is it Unix domain socket? If the # of requests are in a high rate, I think the overhead may come from QMP framework, mostly event loop synchronization: QMP messages are not processed if the device emulation code is running. Also did you try to compress the memory data with zlib, to compensate for the base64 encoding inflation? > > > 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? > > > I'm moving forward to try the Qemu chardev approach now. I haven't working > much with this construct before, so any pointers are appreciated. From > what I'm seeing, it looks like the user would create a chardev using one of > the QMP @chardev* commands? The schema doesn't indicate that these > commands return the chardev id, which seems odd as I was then assuming that > one could obtain the id and pass this into the pmemaccess QMP command. > Thoughts? The chardev will be assigned an "id" by user, as the paremeter of chardev-add, and later the user will pass id to pmemaccess. In pmemaccess implementation, we will find the chardev by qemu_chr_find, and read/write with qemu_chr_* functions. You can take examples from hw/char/* for devices' usage. Fam
