* Xiao Guangrong (guangrong.xiao@xxxxxxxxx) wrote: > > > On 07/11/2018 04:21 PM, Peter Xu wrote: > > On Thu, Jun 28, 2018 at 05:33:58PM +0800, Xiao Guangrong wrote: > > > > > > > > > On 06/19/2018 03:36 PM, Peter Xu wrote: > > > > On Mon, Jun 04, 2018 at 05:55:15PM +0800, guangrong.xiao@xxxxxxxxx wrote: > > > > > From: Xiao Guangrong <xiaoguangrong@xxxxxxxxxxx> > > > > > > > > > > Try to hold src_page_req_mutex only if the queue is not > > > > > empty > > > > > > > > Pure question: how much this patch would help? Basically if you are > > > > running compression tests then I think it means you are with precopy > > > > (since postcopy cannot work with compression yet), then here the lock > > > > has no contention at all. > > > > > > Yes, you are right, however we can observe it is in the top functions > > > (after revert this patch): > > > > > > Samples: 29K of event 'cycles', Event count (approx.): 22263412260 > > > + 7.99% kqemu qemu-system-x86_64 [.] ram_bytes_total > > > + 6.95% kqemu [kernel.kallsyms] [k] copy_user_enhanced_fast_string > > > + 6.23% kqemu qemu-system-x86_64 [.] qemu_put_qemu_file > > > + 6.20% kqemu qemu-system-x86_64 [.] qemu_event_set > > > + 5.80% kqemu qemu-system-x86_64 [.] __ring_put > > > + 4.82% kqemu qemu-system-x86_64 [.] compress_thread_data_done > > > + 4.11% kqemu qemu-system-x86_64 [.] ring_is_full > > > + 3.07% kqemu qemu-system-x86_64 [.] threads_submit_request_prepare > > > + 2.83% kqemu qemu-system-x86_64 [.] ring_mp_get > > > + 2.71% kqemu qemu-system-x86_64 [.] __ring_is_full > > > + 2.46% kqemu qemu-system-x86_64 [.] buffer_zero_sse2 > > > + 2.40% kqemu qemu-system-x86_64 [.] add_to_iovec > > > + 2.21% kqemu qemu-system-x86_64 [.] ring_get > > > + 1.96% kqemu [kernel.kallsyms] [k] __lock_acquire > > > + 1.90% kqemu libc-2.12.so [.] memcpy > > > + 1.55% kqemu qemu-system-x86_64 [.] ring_len > > > + 1.12% kqemu libpthread-2.12.so [.] pthread_mutex_unlock > > > + 1.11% kqemu qemu-system-x86_64 [.] ram_find_and_save_block > > > + 1.07% kqemu qemu-system-x86_64 [.] ram_save_host_page > > > + 1.04% kqemu qemu-system-x86_64 [.] qemu_put_buffer > > > + 0.97% kqemu qemu-system-x86_64 [.] compress_page_with_multi_thread > > > + 0.96% kqemu qemu-system-x86_64 [.] ram_save_target_page > > > + 0.93% kqemu libpthread-2.12.so [.] pthread_mutex_lock > > > > (sorry to respond late; I was busy with other stuff for the > > release...) > > > > You're welcome. :) > > > I am trying to find out anything related to unqueue_page() but I > > failed. Did I miss anything obvious there? > > > > unqueue_page() was not listed here indeed, i think the function > itself is light enough (a check then directly return) so it > did not leave a trace here. > > This perf data was got after reverting this patch, i.e, it's > based on the lockless multithread model, then unqueue_page() is > the only place using mutex in the main thread. > > And you can see the overload of mutext was gone after applying > this patch in the mail i replied to Dave. I got around to playing with this patch and using 'perf top' to see what was going on. What I noticed was that without this patch pthread_mutex_unlock and qemu_mutex_lock_impl were both noticeable; with the patch they'd pretty mich vanished. So I think it's worth it. I ocouldn't honestly see a difference in total CPU usage or bandwidth; but the migration code is so spiky in usage that it's difficult to measure anyway. So, Reviewed-by: Dr. David Alan Gilbert <dgilbert@xxxxxxxxxx> -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
