RE: Commit 282d8998e997 (srcu: Prevent expedited GPs and blocking readers from consuming CPU) cause qemu boot slow

[Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>]

> -----Original Message-----
> From: zhangfei.gao@foxmail.com [mailto:zhangfei.gao@foxmail.com]
> Sent: 13 June 2022 07:56
> To: paulmck@kernel.org
> Cc: Paolo Bonzini <pbonzini@redhat.com>; Zhangfei Gao
> <zhangfei.gao@linaro.org>; linux-kernel@vger.kernel.org;
> rcu@vger.kernel.org; Lai Jiangshan <jiangshanlai@gmail.com>; Josh Triplett
> <josh@joshtriplett.org>; Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com>; Matthew Wilcox <willy@infradead.org>;
> Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> mtosatti@redhat.com; Auger Eric <eric.auger@redhat.com>
> Subject: Re: Commit 282d8998e997 (srcu: Prevent expedited GPs and
> blocking readers from consuming CPU) cause qemu boot slow
> 
 
> By the way, the issue should be only related with qemu apci. not related
> with rmr feature
> Test with: https://github.com/qemu/qemu/tree/stable-6.1
> 
> Looks it caused by too many kvm_region_add & kvm_region_del if
> acpi=force,

Based on the setup I have, I think it has nothing to do with Guest kernel booting with
ACPI per se(ie, acpi=force in Qemu kernel cmd line).
It is more to do with Qemu having the "-bios QEMU_EFI.fd" which sets up
pflash devices resulting in large number of pflash read/write calls(before Guest kernel
even boots) which in turn seems to be triggering the below kvm_region_add/del calls.
 
Thanks,
Shameer

> If no acpi, no print kvm_region_add/del (1000 times print once)
> 
> If with acpi=force,
> During qemu boot
> kvm_region_add region_add = 1000
> kvm_region_del region_del = 1000
> kvm_region_add region_add = 2000
> kvm_region_del region_del = 2000
> kvm_region_add region_add = 3000
> kvm_region_del region_del = 3000
> kvm_region_add region_add = 4000
> kvm_region_del region_del = 4000
> kvm_region_add region_add = 5000
> kvm_region_del region_del = 5000
> kvm_region_add region_add = 6000
> kvm_region_del region_del = 6000
> 
> kvm_region_add/kvm_region_del ->
> kvm_set_phys_mem->
> kvm_set_user_memory_region->
> kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem)
> 
> [  361.094493]  __synchronize_srcu loop=9000
> [  361.094501] Call trace:
> [  361.094502]  dump_backtrace+0xe4/0xf0
> [  361.094505]  show_stack+0x20/0x70
> [  361.094507]  dump_stack_lvl+0x8c/0xb8
> [  361.094509]  dump_stack+0x18/0x34
> [  361.094511]  __synchronize_srcu+0x120/0x128
> [  361.094514]  synchronize_srcu_expedited+0x2c/0x40
> [  361.094515]  kvm_swap_active_memslots+0x130/0x198
> [  361.094519]  kvm_activate_memslot+0x40/0x68
> [  361.094520]  kvm_set_memslot+0x2f8/0x3b0
> [  361.094523]  __kvm_set_memory_region+0x2e4/0x438
> [  361.094524]  kvm_set_memory_region+0x78/0xb8
> [  361.094526]  kvm_vm_ioctl+0x5a0/0x13e0
> [  361.094528]  __arm64_sys_ioctl+0xb0/0xf8
> [  361.094530]  invoke_syscall+0x4c/0x110
> [  361.094533]  el0_svc_common.constprop.0+0x68/0x128
> [  361.094536]  do_el0_svc+0x34/0xc0
> [  361.094538]  el0_svc+0x30/0x98
> [  361.094541]  el0t_64_sync_handler+0xb8/0xc0
> [  361.094544]  el0t_64_sync+0x18c/0x190
> [  363.942817]  kvm_set_memory_region loop=6000
> 
>