On Mon, 13 Jun 2022 16:02:30 +0100, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> wrote: > > > > > -----Original Message----- > > From: zhangfei.gao@xxxxxxxxxxx [mailto:zhangfei.gao@xxxxxxxxxxx] > > Sent: 13 June 2022 07:56 > > To: paulmck@xxxxxxxxxx > > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>; Zhangfei Gao > > <zhangfei.gao@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; > > rcu@xxxxxxxxxxxxxxx; Lai Jiangshan <jiangshanlai@xxxxxxxxx>; Josh Triplett > > <josh@xxxxxxxxxxxxxxxx>; Mathieu Desnoyers > > <mathieu.desnoyers@xxxxxxxxxxxx>; Matthew Wilcox <willy@xxxxxxxxxxxxx>; > > Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx>; > > mtosatti@xxxxxxxxxx; Auger Eric <eric.auger@xxxxxxxxxx> > > 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. Indeed, this is all about memslots being added/removed at an alarming rate (well, not more alarming today than yesterday, but QEMU's flash emulation is... interesting). M. -- Without deviation from the norm, progress is not possible.
