We have hardware already with front side bus speeds of 13 GB/s.
We also already have 5 GB/s RDMA hardware, and we will likely have even faster RDMA hardware in the future. This analysis is not factoring into account the cycles it takes to map the pages before they are checked for duplicate bytes, regardless whether or not very little of the page is actually cached on the processor. This analysis is also not taking into account the possibility that the VM may be CPU-bound at the same time that QEMU is competing to execute is_dup_page(). Thus, as you mentioned, a worst-case 5 GB/s memory bandwidth for is_dup_page() could be very easily reached given the right conditions - and we do have many workloads both HPC and Multi-tier which can easily cause QEMU's zero scanning performance to suffer. - Michael On 04/11/2013 10:15 AM, Paolo Bonzini wrote:
No, I'm saying that is_dup_page() should not be a problem. I'm saying it should only loop a lot during the bulk phase. The only effect I can imagine after the bulk phase is one cache miss. Perhaps the stress-test you're using does not reproduce realistic conditions with respect to zero pages. Peter Lieven benchmarked real guests, both Linux and Windows, and confirmed the theory that I mentioned upthread. Almost all non-zero pages are detected within the first few words, and almost all zero pages come from the bulk phase. Considering that one cache miss, RDMA is indeed different here. TCP would have this cache miss later anyway, RDMA does not. Let's say 300 cycles/miss; at 2.5 GHz that is 300/2500 microseconds, i.e 0.12 microseconds per page. This would say that we can run is_dup_page on 30 GB worth of nonzero pages every second or more. Ok, the estimate is quite generous in many ways, but is_dup_page() is only a bottleneck if it can do less than 5 GB/s. Paolo
