Re: [Qemu-devel] [PATCH 0/3] memory: an optimization

[Paolo Bonzini <pbonzini@redhat.com>]

On 20/02/2016 03:35, Gonglei wrote:
> Perf top tells me qemu_get_ram_ptr consume too much cpu cycles.
>> 22.56%  qemu-kvm                 [.] address_space_translate
>>  13.29%  qemu-kvm                 [.] qemu_get_ram_ptr
>>   4.71%  qemu-kvm                 [.] phys_page_find
>>   4.43%  qemu-kvm                 [.] address_space_translate_internal
>>   3.47%  libpthread-2.19.so       [.] __pthread_mutex_unlock_usercnt
>>   3.08%  qemu-kvm                 [.] qemu_ram_addr_from_host
>>   2.62%  qemu-kvm                 [.] address_space_map
>>   2.61%  libc-2.19.so             [.] _int_malloc
>>   2.58%  libc-2.19.so             [.] _int_free
>>   2.38%  libc-2.19.so             [.] malloc
>>   2.06%  libpthread-2.19.so       [.] pthread_mutex_lock
>>   1.68%  libc-2.19.so             [.] malloc_consolidate
>>   1.35%  libc-2.19.so             [.] __memcpy_sse2_unaligned
>>   1.23%  qemu-kvm                 [.] lduw_le_phys
>>   1.18%  qemu-kvm                 [.] find_next_zero_bit
>>   1.02%  qemu-kvm                 [.] object_unref
> 
> And Paolo suggested that we can get rid of qemu_get_ram_ptr
> by storing the RAMBlock pointer into the memory region,
> instead of the ram_addr_t value. And after appling this change,
> I got much better performance indeed.

What's the gain like?

I've not reviewed the patch in depth, but what I can say is that I like
it a lot.  It only does the bare minimum needed to provide the
optimization, but this also makes it very simple to understand.  More
cleanups and further optimizations are possible (including removing
mr->ram_addr completely), but your patches really does one thing and
does it well.  Good job!

Paolo